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ABSTRACT 


In  light  of  the  continued  investment  in  information 
technology  by  businesses  in  hopes  of  achieving  a  measurable 
benefit  in  terms  of  process  efficiency  and  effectiveness, 
business  process  reengineering  (BPR)  is  becoming 
increasingly  important.  BPR  suggests  that  by  radically 
redesigning  underlying  business  processes,  companies  can 
achieve  breakthrough  improvements  in  productivity.  BPR, 
however,  is  a  knowledge  intensive  endeavor.  A  decision 
support  tool  called  KOPeR-lite  was  developed  with  the 
intent  of  encoding  the  knowledge  held  by  BPR  experts  and 
documented  in  BPR  literature.  This  tool  promises  to  assist 
BPR  novices  who  are  tasked  with  reengineering  inefficient 
or  ineffective  processes.  The  purpose  of  this  thesis  is  to 
determine  the  viability  of  using  KOPeR-lite  when  BPR 
novices  undertake  process  reengineering  projects.  It  also 
proposes  reengineering  solutions  for  the  permanent  change 
of  station  orders  process  for  USMC  officers,  which  will  be 
presented  to  the  leadership  in  the  Headquarter,  U.S.  Marine 
Corps  (HQMC)  Manpower  and  Reserve  Affairs  (M&RA)  branch. 
If  adopted,  one  of  the  proposed  solutions  promises  to 
dramatically  improve  process  performance. 
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INTRODUCTION 


I . 


A.  BACKGROUND 

We  often  hear  the  phrase,  "work  smarter,  not  harder." 
However,  when  working  outside  our  personal  areas  of 
expertise,  this  often  can  become  a  challenge  because  we 
lack  the  resources,  knowledge,  or  human  resources  to  aide 
us.  By  developing  and  using  expert  systems,  we  can  attempt 
to  mitigate  this  problem. 

Expert  systems  are  computerized,  advisory  programs 
that  attempt  to  imitate  the  reasoning  processes  and 
knowledge  of  experts  in  solving  specific  problems.  The 
developers  of  expert  systems  attempt  to  capture  the 
knowledge  held  by  human  experts  by  distilling  their  thought 
processes  and  analytical  techniques  into  a  series  of  rules 
or  heuristics  applicable  within  a  specified  domain.  These 
rules  and  heuristics  are  then  codified  in  a  form  that  a 
computer  can  use  to  analyze  a  problem.  Once  the  expert 
system  is  developed,  a  user  can  input  information 
pertaining  to  a  problem  within  the  domain  for  which  the 
expert  system  was  designed.  The  system  then  will  generate 
proposed  solutions  based  on  its  rule/heuristic  knowledge 
base . 

Though  a  situation  or  process  may  be  novel  to  us  and 
we  may  be  content  to  maintain  the  status  quo,  experts  may 
have  analyzed  a  similar  situation  and  developed  a  more 
effective  process.  Why  not  tap  into  this  expertise  and 
take  a  closer  look  at  the  processes  we're  involved  in  on  a 
daily  basis?  We  thus  ask,  "Is  there  a  better  way  of  doing 
this?"  Expert  systems  may  well  help  us  answer  this  question 
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more  effectively  than  could  a  novice  working  alone,  and  it 
is  hypothesized  that  these  solutions  may  be  equal  in  number 
and  viability  (if  not  better)  and  will  be  generated  in  less 
time  than  it  would  take  a  novice  working  alone. 

B .  OBJECTIVES 

The  purpose  of  this  thesis  is  to  determine  the 
viability  of  using  automated  tools,  such  as  KOPeR-lite, 
when  undertaking  process  reengineering  projects.  It  also 
proposes  reengineering  solutions  for  the  USMC  Personnel 
Assignment  Process,  which  will  be  presented  to  the 
leadership  in  the  Headquarter,  U.S.  Marine  Corps  (HQMC) 
Manpower  and  Reserve  Affairs  (M&RA)  branch.  One  of  the 
proposed  solutions  may  dramatically  improve  process 
performance . 

C .  RESEARCH  QUESTIONS 

The  central  theme  of  this  thesis  is  process 
reengineering,  in  particular  the  efficiency  gains,  process 
flow  improvements  and  decreased  redundancy,  that  may  be 
realized  through  automation  and  other  enablers  of  dramatic 
change.  Currently,  the  process  of  developing  reengineering 
solutions  is  largely  done  using  manual  techniques  that 
demand  extensive  knowledge  and  expertise.  To  this  end,  the 
primary  research  question  is:  How  can  automated  tools  such 
as  KOPeR-Lite  enable  reengineering  novices  to  develop  good, 
viable  reengineering  solutions?  Secondary  questions 
include : 
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What  is  reengineering,  and  what  computer  based 
tools  are  currently  available  for  process- 
redesign  automation  and  support? 

How  does  KOPeR-lite  function,  and  what  evidence 
exists  concerning  its  redesign  effectiveness? 

Which  important  U.S.  Marine  Corps  processes  offer 
good  potential  for  reengineering? 

How  can  KOPeR-lite  be  employed  to  redesign 
important  processes  in  the  U.S.  Marine  Corps? 

How  can  the  results  of  this  study  be  generalized 
to  other  organizations  and  processes? 


D.  SCOPE  OF  THESIS 

The  scope  includes  review  of  materials  on  knowledge- 

based  systems,  decision  support  systems,  and  process 
reengineering.  An  analysis  of  experimental  data  are  then 
performed  to  assess  the  effectiveness  of  KOPeR-lite. 
Finally,  it  draws  from  the  results  of  this  analysis  to 

apply  these  and  other  applicable  techniques  in 
reengineering  the  processed  followed  in  making  USMC 
Personnel  Assignment  decisions. 

E .  RESEARCH  METHODOLOGY 

The  methodology  used  in  this  thesis  research  consists 
of  reviewing  data  from: 

•  Existing  material  (i.e.  books,  professional 
journals,  the  web,  etc)  ; 

•  Data  generated  by  students  tasked  with 

reengineering  software  engineering  processes;  and 

•  Information  from  HQMC  and  1st  Force  Service 

Support  Group  (FSSG)  on  the  existing  process  for 
personnel  assignments,  to  include:  Marine  Corps 
directives  pertaining  to  the  personnel  assignment 
process  as  well  as  information  gathered  via 
personal  interviews. 
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The  research  method  also  includes  process  analysis  using 
the  Davenport  framework  and  using  results  from  analysis  of 
experimental  data  associated  with  KOPeR-lite  to  redesign 
the  U.S.  Marine  Corps  Personnel  Assignment  process. 
Analysis  of  experimental  data  is  accomplished  through  the 
method  of  content  analysis,  and  analyses  of  at  least  two 
researchers  are  integrated  for  reliability.  Reengineering 
is  accomplished  through  a  combination  of  Davenport's  five- 
step  process:  (1)  Identifying  Processes  for  Innovation;  (2) 
Identifying  Change  Levers;  (3)  Developing  Change  Levers; 
(4)  Understanding  Existing  Processes;  and  (5)  Designing  and 
Prototyping  New  Processes  (including  use  of  KOPeR-lite) . 

The  data  obtained  are  then  used  to  make 
recommendations  to  usefulness  of  KOPeR-lite  in  process 
reengineering  and  propose  a  reengineered  solution  to  the 
current  personnel  assignment  process. 

In  order  to  analyze  and  develop  a  reengineering 
solution  to  the  current  U.S.  Marine  Corps  Personnel 
Assignment  process,  data  are  gathered  on  the  baseline 
process  by  reviewing  pertinent  orders  and  directives  which 
outline  current  processes  as  well  as  by  interviewing 
manpower  personnel  at  a  Major  Subordinate  Command, 
specifically  1®^  Force  Service  Support  Group  (FSSG)  aboard 
Marine  Corps  Base  Camp  Pendleton.  Once  this  is  done, 
attributes  of  the  baseline  process  are  delineated  and 
employed  for  KOPeR-lite  analysis  and  process  pathology 
identification.  Based  on  KOPeR-lite' s  proposed 
transformations,  one  or  more  redesigns  are  developed  and 
included.  Following  this,  the  redesign  is  provided  to  the 
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Assistant  Chief  of  Staff,  G-1,  FSSG  for  review  and 

comment . 

F.  ORGANIZATION 

This  thesis  is  organized  as  follows.  Following  this 
introduction.  Chapter  II  provides  a  brief  historical 
outline  of  process  reengineering  and  why  it  is  pursued. 
Additionally,  the  Davenport  framework  is  presented  along 
with  a  functional  description  of  KOPeR-lite.  KOPeR-lite  is 
used  to  depict  processes  and  gain  an  understanding  for 
redesign.  Chapter  III  covers  the  experimental  design, 
data,  analysis,  results  and  implications.  Chapter  IV 
addresses  the  matter  of  reengineering  the  permanent  change 
of  station  (PCS)  orders  process  for  USMC  officers.  Chapter 
V  summarizes  the  results  of  research  and  study  as  well  as 
makes  recommendations  for  process  improvement  and  areas  for 
future  research. 
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II.  PROCESS  REENGINEERING 


A.  HISTORICAL  BASIS 

The  assembly  line,  the  cotton  gin,  the  type  setting 
machine,  and  the  typewriter:  these  are  all  examples  of 
concepts  or  inventions  which  led  to  quantum  leap 
improvements,  such  as  increased  productivity,  reduced 
costs,  and  reduced  labor.  Each  time  an  invention  or  new 
concept  is  developed,  underlying  processes  in  the  domain  in 
which  it  is  to  be  implemented  must  be  evaluated  for  radical 
change  so  that  the  full  potential  of  the  invention  or  new 
concept  may  be  realized.  Business  process  reengineering 
(BPR)  suggests  that  by  radically  redesigning  their  business 
processes,  companies  can  achieve  breakthrough  improvements 
in  productivity. 


B .  WHY  REENGINEER 

Today,  some  of 

the 

catalysts 

for 

change 

include 

increased  competition. 

both 

domestic 

and 

foreign. 

greater 

availability  of  information  to  customers  about  competing 
products,  a  shift  from  manufacturing  to  service  industries, 
and  the  advent  of  new  technologies.  The  latter  has  become 
arguably  the  biggest  driver  for  change  over  the  past 
decade.  Companies  both  large  and  small  have  made  large 
capital  investments  in  technology  only  to  realize  little  if 
any  quantifiable  improvements  in  productivity. 

One  cannot  invest  in  technology  and  then  simply  cross 
one's  fingers  and  hope  for  the  best.  A  plan  must  be 
formulated  to  ensure  underlying  business  processes  are 
adapted  to  make  full  use  of  the  capabilities  afforded  by 
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technology.  This  includes  analyzing  process  workflow, 
removing  non-value  added  steps,  reducing  process  friction, 
reducing  the  number  of  independent  reviews  or  burdensome 
oversight  functions,  increasing  information  flow  (and 
getting  the  right  information  to  the  right  people) ,  and 
providing  training,  among  other  things. 

Given  the  ever-increasing  pace  of  change  in  the 
business  environment,  the  question  asked  by  businesses 
should  no  longer  be  "do  we  need  to  change?"  Rather, 
businesses  need  to  ask  "How  can  we  best  change,  not  only  to 
maintain  relevance  in  the  changing  environment,  but  to 
realize  order  of  magnitude  improvement  to  develop  or 
maintain  our  competitive  advantage?" 

C .  DAVENPORT  FRAMEWORK 

Davenport  (Davenport,  1993)  advocates  a  five-step 
process  in  the  conduct  of  BPR,  as  depicted  in  Figure  2-1. 

Identifying  Processes  for  Innovation 


Identifying  Change  Levers 


Developing  Process  Visions 


Understanding  Existing  Processes 


Designing  and  Prototyping  the  New  Process 


Figure  2-1 . 


A  High-Level  Appproach  to  Process  Innovation 
(From  Davenport,  1993,  pg  200) 


Before  setting  a  course  for  change,  either  incremental  or 
radical,  a  company  must  first  develop  a  clear  understanding 
of  its  current  state  of  affairs.  By  following  the 
methodology  he  outlines,  an  organization  will  gain  a 
thorough  understanding  of  its  existing  processes,  determine 
what  needs  to  be  accomplished  in  order  to  facilitate 
change,  develop  redesigns  for  pathological  processes,  as 
well  as  develop  a  plan  for  implementing  the  change.  A 
clear  understanding  of  existing  processes,  identification 
of  associated  pathologies,  and  a  decision  as  to  whether  or 
not  change  is  needed  are  of  critical  importance  to  this 
methodology . 

1.  Identifying  Processes  for  Innovation 

For  our  purposes,  a  process  is  defined  as  any 
collection  of  activities  that  yield  some  output  of  value. 
This  output  could  be  an  input  to  follow-on  processes  or 
perhaps  some  good  or  service.  The  case  study  contained  in 
Appendix  A,  for  example,  shows  the  baseline  software 
development  process  comprises  six  fundamental  activities: 
sales,  requirements  development,  design,  code,  test,  and 
independent  test  and  evaluation  (IV&V) .  In  this  particular 
process,  each  activity  follows  the  one  before  in  a  simple 
linear  manner  (See  Figure  2-2  above)  . 
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Figure  2-2.  Baseline  Process  Activity  Flow  for  the 
Software  Development  Case  Contained  in  Appendix  A 


Davenport  proposes  four  criteria  to  aide  in  selecting 
processes  for  innovation: 

(1)  the  process's  centrality  to  the  execution  of 
the  firm' s  business  strategy, 

(2)  process  health, 

(3)  process  qualification,  and 

(4)  manageable  project  scope.  The  goal  of  process 
innovation  is  order  of  magnitude  improvement  in 
the  effectiveness  or  efficiency. 

Unlike  incremental  change,  which  is  typically  a 
continuous  evolution,  process  innovation  should  be  a 
discrete,  focused  effort.  By  selecting  a  process  that  is 
closely  related  to  the  overall  business  strategy  (e.g.  the 
software  development  process  for  a  company  that  creates 
software  solutions  for  its  clients) ,  the  effects  of  the 
change  will  be  felt  more  profoundly  than  would  likely  be 
the  case  if  a  non-core  process  is  chosen  for  a  innovation 
initiative . 

With  regard  to  process  health,  the  more  pathologies 
exhibited  by  the  selected  process,  the  greater  the 
potential  gains  one  may  realize  by  reengineering  it. 
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with  regard  to  process  qualification,  culture  of 
political  climate  must  be  such  that  innovation  efforts  will 
be  well  received.  Also,  a  committed  sponsor  of  the 
innovation  efforts  must  be  present  if  there  is  to  be  any 
hope  for  success.  Last,  Davenport  advises  that  the 
project's  scope  be  well  defined  to  provide  focus  to  the 
innovation  process. 

2 .  Identifying  Change  Levers 

The  application  of  information  technology  (IT)  as  a 
change  lever  is  one  of  Davenport's  foci,  in  part  because  of 
the  increasing  incorporation  of  and  reliance  on  IT  tools  in 
the  day-to-day  activities  of  most  businesses.  Another 
reason  for  this  focus  is  that  most  businesses  have  failed 
to  realize  the  full  potential  of  their  IT  investment. 
Other  change  levers  include  training,  workflow  redesign, 
employee  empowerment,  and  changes  in  organizational  design. 
By  using  a  combination  of  these  tools,  business  may  more 
fully  realize  the  benefits  afforded  by  IT. 

3.  Developing  Process  Visions 

"Common  sense  tells  us  that  a  change  must  be  'seen, ' 
its  direction  somewhat  charted,  before  anything  happens." 
(Jick,  1993,  pg  75)  A  vision  statement  provides  a  clear 
picture  of  the  end  state  desired.  It  provides  participants 
a  clear  sense  of  what  they  are  working  to  achieve  and  helps 
to  focus  their  efforts.  Further,  "alignment  between 
[corporate]  strategies  and  processes  is  essential  to 
radical  change  in  business  processes."  (Davenport,  1993, 
pg  117)  Additionally,  "process  change  without  strategy  and 
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vision  seldom  goes  beyond  streamlining,  with  a  resulting 
incremental  reduction  in  time  and  cost."  (Davenport  1993,  p 
119)  A  vision,  therefore,  is  necessary  if  there  is  to  be 
any  hope  for  achieving  the  results  desired. 

4 .  Understanding  Existing  Processes 

Until  a  clear  understanding  of  the  baseline  process  is 
developed,  changes  will  produce  haphazard  results.  By 
developing  a  firm  understanding  the  existing  process,  one 
can  more  intelligently  go  about  finding  solutions  for  the 
processes'  associated  pathologies.  Davenport  articulates 
four  reasons  why  it  is  important  to  develop  a  clear 
understanding  of  existing  processes:  (1)  understanding 
existing  processes  facilitates  communication  among 
participants  in  the  innovation  initiative;  (2)  in  most 
complex  organizations  there  is  no  way  to  migrate  to  a  new 
process  without  understanding  the  current  one;  (3) 
recognizing  problems  in  an  existing  process  can  help  ensure 
that  they  are  not  repeated  in  the  new  process;  and  (4)  an 
understanding  of  the  current  process  provides  a  measure  of 
the  value  of  the  proposed  innovation.  (Davenport,  1993) 

5.  Designing  and  Prototyping  the  New  Process 

For  the  activity  of  designing  new  processes,  Davenport 
states  that  "the  design  activity  is  largely  a  matter  of 
having  a  group  of  intelligent,  creative  people  review  the 
information  collected  in  earlier  phases  of  the  initiative 
and  synthesize  it  into  a  new  process"  and  that  "the  success 
or  failure  of  the  effort  will  turn  on  the  particular  people 
who  are  gathered  together."  (Davenport,  1993,  pg  153) 
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In  developing  new  process  designs,  he  advocates  using 
brainstorming  sessions.  The  goal  of  these  sessions  is 
generating  creative  alternatives  by  all  participants  in  a 
non- judgmental  atmosphere.  Graphic  representation  of  the 
redesigns  is  recommended  as  it  helps  understand  process 
flows . 

Following  redesign  generation,  participants  must 
assess  feasibility,  risk,  and  benefits  of  the  alternatives 
in  terms  of  overall  strategy  and  vision.  Prototyping  of 
redesigns  is  "an  iterative  process  in  which  the  fit  between 
new  process  structure,  information  technology  and 
organization  is  refined  and  re-refined."  (Davenport,  1993, 
p  156)  The  output  of  this  prototyping  activity  is  the 
selection  of  a  redesign  for  implementation. 

D .  KOPER-LITE 

KOPeR-lite  is  a  web-based  version  of  The  Knowledge- 
Based  Organizational  Process  Redesign  (KOPeR)  tool  that  was 
originally  implemented  in  a  UNIX  environment.  KOPeR-lite 
is  an  automated  tool  created  to  help  BPR  novices  develop 
process  redesign  alternatives  without  the  benefit  of 
extensive  training  in  BPR  or  from  the  brainstorming 
sessions  highlighted  in  Davenport's  framework.  It  does 
this  by  making  recommendations  based  on  its  analysis  of  the 
metrics  inputted  by  the  user  for  each  measure  listed  in 
Table  2-1  below. 
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Measure 

Graph  Based  Definition 

Process  Length 

Number  of  nodes  in  longest  path 

Process  Breadth 

Number  of  distinct  paths 

Process  Depth 

Number  of  process  levels 

Process  Size 

Number  of  nodes  in  process  model 

Process  Feedback 

Number  of  cycles  in  graph 

Parallelism 

Process  Size  divided  by  Length 

IT  Support 

Number  of  IT-support  attributes 

IT  Communication 

Number  of  IT-communicat ion  attributes 

IT  Automation 

Number  of  IT-automat ion  attributes 

Organizational 

Number  of  unique  agent  role 

Roles 

attributes 

Process  Handoffs 

Number  of  interrole  edges 

Organizations 

Number  of  unique  agent  org. 
attributes 

Value  Chains 

Number  of  unique  activity  Value  Chain 
attributes 

Table  2-1.  Example  Process  Measure  (From  Nissen,  2000) 


Once  these  metrics  have  been  entered,  KOPeR-lite 
carries  out  its  two  primary  functions:  (1)  pathology 
diagnosis  and  (2)  transformation  matching  by  referencing 
its  knowledge  base.  This  knowledge  base  is  composed  of 
three  component  parts:  (1)  process  pathologies  (2)  redesign 
transformations  and  (3)  process  models.  (Nissen,  2000). 
Pathologies  are  identified  by  a  series  of  IF-THEN  rules 
applied  by  KOPeR-lite  to  the  user  inputted  process 
measurements.  Based  on  KOPeR-lite' s  analysis  of  the 
metrics,  it  provides  the  user  with  feedback  identifying 
process  pathologies.  These  pathologies  include  those 
listed  in  Table  2.2  below. 
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Pathology  Class 

Sample  Instance 

Problematic  process 

Sequential  process  flows 

structure 

Bureaucratic  organization 

Job  specialization 

Fragmented  process  flows 

Process  friction 

IT  infrastructure 

Manual  process 

Checking"  approach  to 

Review-intensive  process 

quality 

Centralized  authority 

Long  decision  chains 

Under-utilized  human 

Training  emphasis 

potential 

Inhibitive  leadership 

Directive  supervision 

Centralized  information 

Central  database  architecture 

Deficient  core  competency 

Low  IT  expertise 

Table  2-2.  Pathologies  and  Pathology  Samples  (From 


Nissen,  2000) 


KOPeR-lite  then  carries  out  its  second  function:  that 
of  transformation  matching.  The  transformations  it 

proposes  are  drawn  from  its  transformation  knowledge  base 
following  the  application  of  another  series  of  IF-THEN 
rules.  The  knowledge  base  is  populated  with  expertise 
gleaned  from  BPR  literature.  Some  of  the  transformations 
KOPeR-lite  may  propose  are  listed  below  and  address  the 


pathologies  listed  in  Table  2-2. 


Transformation  Class 

Sample  Instance 

Workflow  reconfiguration 

Process  delinearization 

Information  technology 

Shared  database  system 

Crganizational  design 

Case  manager 

Human  resource 

Team-based  compensation 

Information  availability 

Informant  agents 

Inter- organizational 

Supplier-managed  inventory 

alliance 

Management  &  culture 

Employee  stock  ownership 

Table  2-3.  Taxonomy  of  Redesign  Transformations  (From 

Nissen,  2000) 
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E.  HOW  MIGHT  THE  MILITARY  BENEFIT  FROM  PROCESS 
REENGINEERING  EFFORTS 

There  are  numerous  ways  the  military  could  benefit 
from  using  such  a  tool.  Ask  just  about  anyone  in  the 
military  if  they  have  experienced  a  process  that  they  felt 
was  less  than  efficient,  and  you  will  almost  assuredly 
receive  a  long  list  of  processes  that  they  feel  have  room 
for  improvement. 

Some  examples  are  listed  below: 

(1)  USMC  Personnel  Assignment  Process.  There  are 
numerous  sources  that  a  major  command  uses  to  find  out  who 
is  coming  to  their  command.  Unfortunately,  there  is  no  one 
single  source  and  the  multiple  sources  have  different 
degrees  of  accuracy.  By  being  able  to  more  effectively 
identify  inbound  personnel  well  in  advance  of  their 
arrival,  personnel  sections  would  be  able  to  make  better 
assignments  and  offer  inbound  personnel  with  better 
assistance  during  the  somewhat  hectic  permanent  change  of 
station  process.  Additionally,  receiving  commands  would  be 
able  to  make  better  plans  based  on  projected  personnel  end 
strengths . 

(2)  Transition  to  Smart  Card  Technologies.  There  are 
numerous  initiatives  being  pursued  with  regard  to  smart 
card  technologies.  Some  of  the  issues  raised  are:  How  will 
we  collect  information  from  various  sources  for  personnel, 
messing,  billeting,  armory,  and  others,  and  fuse  them  to  be 
carried  or  accessed  using  a  single  card?  How  will  the 
cards  be  issued  and  tracked?  How  will  lost  cards  be  taken 
out  of  the  system  and  replacement  cards  issued?  Failure  to 
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address  these  processes  prior  to  implementing  this 
technology  could  result  in  significant  problems. 

(3)  The  Marine  Corps'  Total  Force  System  (MCTFS) 
Initiatives.  One  such  initiative  is  with  regard  to  Unit 
Diary  (UD)  ownership.  Information  contained  in  MCTFS  is 
updated  periodically  based  on  information  submitted  via  UD^. 
Currently,  only  a  unit's  personnel  administration  section 
submits  information  via  UD .  All  other  sections  that  need  to 
post  information  to  MCTFS  must  submit  the  disparate  source 
documents  to  the  personnel  section  for  processing.  The 
information  contained  on  these  source  documents  is  then  re¬ 
entered  into  the  UD's  proprietary  format  for  reporting  to 
MCTFS.  Once  a  UD  is  prepared,  a  hard  copy  is  printed  and 
submitted  to  the  unit's  Personnel  Officer  for  review  and 
certification.  Once  certified,  the  UD  is  forwarded  for 
incorporation  into  MCTFS.  However,  MCTFS  is  not  a  real¬ 
time  system.  For  non-pay  related  information,  there  is  a 
delay  in  preparing,  certifying,  and  submitting  UD's.  Pay 
related  information  is  handled  somewhat  differently  and  is 
only  incorporated  this  twice  each  monthly  through  the 
update  and  extract  process.  This  is  a  source  of 

inefficiency  and  causes  problems  most  often  seen  with 
regard  to  personnel  pay  and  promotion. 

Total  Force  Administration  System  (TFAS)  represents  a 
new  initiative  in  the  realm  of  Marine  Corps  Personnel 
Administration.  TFAS  actually  is  a  front-end  system  that 
is  tied  to  MCTFS.  Individual  Marines  will  be  able  to 
change  or  request  changes  to  certain  information  via  the 

^  Unit  Diaries  (UD's)  contain  information  reported  in  a  proprietary 
format  which  automates  the  process  of  updating  information  contained  in 
MCTFS . 
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web  rather  than  relying  on  Marines  working  in  his  or  her 
unit's  personnel  administration  section.  The  unit 
Commander  (e.g.  company  or  battalion  commanders)  will  have 
the  ability  to  enter  such  things  as  training  and  morning 
report  information  directly  into  the  system.  Access  at 
this  level  is  referred  to  as  second  echelon  access.  Third 
Echelon  will  comprise  three  TEAS  centers  located  at  the 
major  installations.  These  centers  will  submit  information 
requiring  expertise  or  oversight.  Eorth  echelon  consists 
of  call  centers  which  will  be  available  24  hours  to  provide 
assistance  to  system  users.  The  highest  echelon,  fifth 
echelon,  is  Headquarters,  U.S.  Marine  Corps  (M&RA) . 

How  can  TEAS  best  be  used  to  increase  the  efficiency 
of  current  personnel  administration  processes?  Considering 
the  plethora  of  information  that  must  be  updated  in  MCTES 
on  a  routine  basis,  removing  any  bottle  necks  and  speeding 
up  the  process  would  result  in  more  accurate,  timely 
information  being  maintained  and  saving  numerous  man-hours 
of  labor. 

(4)  Personnel  Housing  Assignment.  The  recent  push  to 
privatize  base  housing  presents  a  good  opportunity  to 
review  current  housing  management  processes.  Again,  there 
are  numerous  sources  that  may  be  accessed  to  determine  when 


current 

residents 

will 

be 

moving  and 

when  future  service 

members 

who 

want 

to 

be 

assigned  to 

base  housing 

will 

arrive . 

How 

can 

we 

better  manage 

and  coordinate 

this 

information . 

(5)  Repair  parts/supply  requisitioning  process.  This 
area  has  seen  numerous  initiatives  in  recent  years.  Erom 
migrating  to  a  more  just-in-time  inventory  type  system  to 
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eliminating  non-value  added  steps,  improvements  have  been 
made.  However,  it  is  still  a  problematic  area  where 
efficiencies  can  be  gained  and  increased  effectiveness  may 
be  realized. 

These  are  just  a  few  problem  areas  within  the  military 
that  could  benefit  from  the  application  of  a  BPR  tool  such 
as  KOPeR-lite  to  develop  process  redesigns.  The  results  of 
implementing  more  efficient,  effective  process  may  include: 

-  Cost  savings; 

-  Reduction  in  the  number  of  personnel  needed  in  the 
execution  of  various  processes; 

-  Increased  customer  satisfaction.  (The  customer 
ranges  from  individual  service  members  to  the 
nation,  from  individual  commands  to  civilian 
contractors . ) 


G.  SUMMARY 


The 

goal  of 

BPR  is  to 

produce 

quantum 

leap 

improvements  in  the 

efficiency 

and  effectiveness 

in 

business 

processes . 

The  need  to 

conduct 

BPR  has 

not 

diminished  since  the  term  was  originally  coined.  Rather, 
the  significant  improvements  in  the  realm  of  technology, 
rapid  improvement  in  information  availability  (driven 
largely  by  advances  in  technology)  ,  as  well  as  the 
implementation  of  new  technologies  without  changing 
underlying  processes  all  necessitate  continued  or  renewed 
BPR  efforts. 

Davenport  provides  us  with  a  framework  within  which  to 
pursue  BPR  efforts.  KOPeR-lite  provides  us  with  a  tool  to 
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automate  two  knowledge  intensive  steps  in  the  BPR  process: 
(1)  pathology  diagnosis  and  (2)  transformation  matching. 
The  goal  of  the  subsequent  chapter  is  validate  the  benefit 
of  KOPeR-lite. 
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III.  BUSINESS  PROCESS  REENGINEERING  EXPERIMENT 


A.  EXPERIMENTAL  DESIGN 

The  hypothesis  to  be  tested  in  the  experiment  is: 
Will  using  KOPeR-lite  result  in  BPR  novices  producing  (1)  a 
greater  number  of  redesign  alternatives  and  (2)  redesigns 
that  are  higher  in  quality  with  regard  to  feasibility  and 
overall  impact? 

Two  test  groups  are  drawn  from  the  pool  of  graduate 
students  attending  the  Naval  Postgraduate  School.  Students 
selected  to  participate  in  the  experiment  are  screened  to 
ensure  novice  status,  meaning  they  had  no  prior  BPR 
experience,  and  each  receives  a  one-hour  period  of 
instruction  on  re-engineering.  This  period  of  instruction 
was  given  well  in  advance  of  the  laboratory  period  where 
they  would  be  tasked  with  developing  redesigns  for  the  case 
contained  in  Appendix  A.  This  afforded  the  students  the 
opportunity  to  assimilate  the  information  presented  during 
the  period  of  instruction. 

The  experiment  was  conducted  during  the  course  of  a 
single,  two  hour  long  laboratory  period  during  which  the 
students  are  instructed  to  develop  as  many  distinct 
redesign  alternatives  as  they  can.  Given  the  time 
limitation,  speed  of  redesign  generation  is  a  significant 
factor  in  the  number  of  redesigns  generated  per  subject. 
Effectiveness  of  the  redesigns  is  another  major 
consideration . 

For  the  laboratory  period,  the  first  group  is  tasked 
to  generate  redesigns  without  the  use  of  KOPeR-lite  and  the 
second  with  KOPeR-lite. 
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The  redesigns  generated  are  then  analyzed  based  on  the 
following  criteria: 

•  Number  of  redesigns  generated 

•  Delinearization  of  process  flows 

•  Enablers : 

•  Information  technology 

•  Organizational  Design  (other  than  through 

the  injection  of  IT) 

•  Change  in  the  number  of  activities 

•  Change  in  the  number  of  feedback  loops 

•  Change  in  the  number  of  handoffs 

•  Clarity  of  the  redesign,  and 

•  Impact 

1 .  Number  of  Redesigns  Generated 

Redesigns  needed  to  be  distinct  in  that  a  reader 
should  be  easily  able  to  determine  where  one  redesign 

description  ends  and  another  begins.  In  some  cases, 
redesigns  are  presented  simultaneously  in  a  fashion  such 
that  one  is  unable  to  discern  which  features  belong  to 
which  redesign.  In  such  cases,  the  analyst  was  forced  to 
use  his  or  her  best  judgment  to  determine  the  number  of 
redesigns  generated  by  the  experimental  subject. 

2 .  Delinearization 

Delinearization  means  that  two  or  more  activities  that 
were  carried  out  sequentially  in  the  baseline  process  are 
carried  out  simultaneously  in  the  redesign.  Activities 
could  be  grouped  together  in  the  redesign  without 

necessarily  resulting  in  delinearization.  For  example,  the 
design  and  test  activities  could  be  merged  into  a  single 
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cell  where  the  coders  must  still 


"software  development" 
wait  for  the  designers'  output  before  they  can  commence 
work.  Therefore,  the  flow  is  still  sequential.  However, 
if  this  "software  development"  cell  uses  cyclic  development 
or  modular  design,  the  designers  could  pass  on  to  the 
coders  the  design  for  a  single  module  so  that  they  may 
commence  coding  while  the  designers  continue  designing 
additional  modules.  In  this  case,  delinearization  has  been 
incorporated  into  the  redesign.  A  binary  (yes/no,  1/0) 
determination  was  made  for  this  criterion. 

3 .  Enablers 

An  enabler  is  anything  that  results  in  increased 
process  efficiency  or  effectiveness.  Enablers  include,  but 
are  not  limited  to:  information  technology  such  as  shared 
databases,  computer  networks,  electronic  mail  (e-mail) , 
automated  forms,  video  teleconference,  computer  aided 
software  engineering  (CASE)  tools;  organizational  design 
enhancements  such  as  grouping  of  related  activities  to 
facilitate  information  exchange  and  work  coordination  or 
inclusion  of  a  case  manager  who  would  have  oversight  over  a 
group  of  activities;  and  human  resource  factors  such  as 
enhanced  training  or  other  personnel  support  initiatives. 
Each  example  of  an  enabler  incorporated  into  a  redesign  was 
counted  and  the  overall  number  of  enablers  per  redesign 
tallied.  An  enabler  that  was  used  multiple  times  within  a 
single  redesign  was  only  counted  once.  Eor  example,  e-mail 
may  be  used  in  four  activities  within  the  redesign,  however 
the  e-mail  enabler  is  counted  only  once  for  that  redesign. 
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4 .  Change  in  the  Number  of  Activities 

The  number  of  activities  in  a  redesign  process  may 
increase  or  decrease  from  the  number  included  in  the 
baseline.  It  is  hoped  that  by  adding  or  removing  an 

activity,  the  overall  efficiency  and  effectiveness  of  the 
process  workflow  will  be  enhanced.  For  example,  the  sales 
activity  might  be  eliminated  as  superfluous  under  the 

supposition  that  customers  can  communicate  their  software 
needs  to  the  software  development  company  via  telephone  or 
a  website  vice  going  through  a  software  development 
marketing  agent. 

5 .  Change  in  the  Number  of  Feedback  Loops 

A  feedback  loop  occurs  any  time  information  or  a 

product  from  one  activity  is  provided  to  an  activity 
earlier  in  the  process.  For  example,  if  the  Independent 
Verification  and  Validation  (IV&V)  activity  finds  a  flaw  or 
deficiency  in  the  software  product,  IV&V's  finding  must  be 
sent  to  earlier  activities  (e.g..  Design  and/or  Code)  so 

that  the  deficiencies  can  be  addressed.  Sometimes,  as  in 
the  case  of  micromanagement,  excessive  feedback  loops 
inhibit  efficiency  and  should  be  eliminated. 

6.  Change  in  the  Number  of  Handoffs 

The  number  of  handoffs  occurring  in  the  process 
workflow  is  dependent  on  the  overall  number  of  activities 
as  well  as  the  manner  in  which  they  are  carried  out.  An 
example  of  how  the  number  of  handoffs  may  be  reduced  while 
keeping  the  overall  number  of  activities  the  same  is 
depicted  in  Figure  3-1. 
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Baseline  Process  Workflow 
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Redesigned  Process  Workflow 


A:  Sales 

B :  Requiremenb 
C :  Design 
l=):Handafr 
I  I  :  Activity  Graiping 


D:  Code 

E:Test 

F;IV&V 


O: 


:  Activity 


Figure  3-1.  Redesign  Example  Highlighting  a  Reduction  in 

the  Number  of  Handoffs 


In  this  example,  activities  B  and  C  as  well  as  D  and  E  are 
combined  into  two  integrated  activities.  By  doing  this, 
the  number  of  handoffs  is  reduced  from  five  to  three. 


7 .  Clarity  of  the  Redesign 

Essentially,  this  is  the  ease  with  which  one  is  able 
to  discern  the  features  of  a  proposed  redesign.  A  scale 
from  one  to  three  was  used.  The  following  criteria  were 
applied  in  attempts  to  objectify  this  largely  subjective 
metric : 

•  1  -  not  very  clear;  no  redesign  graphic,  redesign 
metrics  are  not  included,  textual  description 
fails  to  enhance  a  reader' s  ability  to  discern 
what  the  author  is  trying  to  convey. 

•  2  -  clear;  a  redesign  graphic  or  metrics  are 

provided,  textual  description  provides  the  reader 
with  a  good  understanding  of  the  author's 
redesign.  Redesigns  where  the  author  provided 
both  a  redesign  graphic  and  metrics  but  provided 
a  mediocre  textual  description  are  also  assigned 
a  value  of  clarity  value  of  2 . 
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3  -  very  clear;  both  a  redesign  graphic  and 
redesign  metrics  are  included  and  the  textual 
description  provides  the  reader  with  an 
exceptionally  clear  mental  picture  of  the 
author's  redesign. 


8 .  Impact 

A  scale  from  one  to  three  is  used.  The  following 
criteria  were  applied  to  objectify  this  basically 
subjective  category: 

•  1  -  infeasible  or  feasible  but  negligible  impact 

•  2  -  feasible  and  moderate  gains  in  efficiency  and 
effectiveness  of  the  process  workflow  anticipated 

•  3  -  feasible  and  significant  gains  in  efficiency 
and  effectiveness  of  the  process  workflow 
anticipated 


B .  ASSESSMENT  PROCEDURE 

The  software  development  case  contained  in  Appendix  A 
was  presented  to  two  groups  of  graduate  students  at  the 
Naval  Postgraduate  School.  The  redesigns  produced  by  each 
experimental  subject  were  then  analyzed  based  on  the 
criteria  listed  in  Section  A  above.  Two  separate  analyses 
were  conducted:  one  by  the  author  and  another  researcher. 
Once  these  separate  analyses  were  completed,  both 
researchers  met  to  discuss  their  individual  findings  and  to 
generate  a  single,  integrated  analysis.  Once  the 
integrated  analysis  was  generated,  several  methods  of 
statistical  manipulation  were  applied  to  the  quantitative 
data.  The  outcome  of  this  analysis  provides  the  basis  for 
the  conclusions  drawn  at  the  end  of  this  chapter.  Appendix 
B  documents  individual  and  integrated  analyses  as  well  as 
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providing  explanatory  comments  documenting  the  rationale 
behind  the  quantitative  assessments. 

C .  EXPERIMENTAL  RESULTS 

The  data  contained  in  Appendix  B  were  then  distilled 
and  entered  into  a  spreadsheet  for  statistical  analysis. 
First  the  independent  analyses  were  reviewed  to  determine 
interjudge  reliability.  Following  this,  an  integrated 

analysis  was  conducted  to  determine  whether  or  not  KOPeR- 
lite  provided  the  BPR  novices  in  the  experimental  group 
with  any  quantifiable  benefits. 

1.  Inter judge  Reliability 

As  stated  above,  one  of  the  first  goals  was  to 
identify  any  significant  inter judge  differences.  Three 
basic  metrics  were  used:  arithmetic  mean,  standard 

deviation,  and  correlation.  Ideally,  there  would  be  no 
difference  in  arithmetic  means  or  standard  deviations,  and 
unity  correlation  for  each  variable  between  the  two 
researchers  would  exist.  Departures  from  the  "ideal" 
results  are  discussed  below. 

a.  Delinearization 

Delinearization  was  a  binary  criterion.  A 

redesign  either  did  or  did  not  apply  delinearization, 
resulting  in  the  assignment  of  a  1  or  0  respectively. 
Differences  stem  from  an  initial  difference  of  opinion 
about  what  constituted  delinearization  (note  the 
particularly  low  correlation  of  0.22415).  It  was  decided 
that  a  value  of  1  would  be  assigned  only  for  those 
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redesigns  where  activities  were  explicitly  identified  to  be 
done  in  parallel  or  where  modular  development  techniques  in 
conjunction  with  a  development  team  concept.  After 
reconciling  these  initial  differences  in  opinion,  the  two 
researchers  attained  98.7%  agreement  on  delinearization 
assessment . 


b.  IT  Enablers 

Prior  to  discussing  their  ratings,  the 
correlation  between  the  two  researchers  on  this  criterion 
is  0.86  indicating  that  significant  agreement  exists. 
Following  discussions,  the  two  researchers  attained  100% 
agreement . 


c.  Non-IT  Enablers 

One  judge  focused  exclusively  on  IT  enablers  and 
failed  to  take  into  account  any  other  enablers  incorporated 
in  the  various  redesigns.  Since  data  for  this  criterion 
was  only  available  from  one  of  the  two  judges,  no 
conclusions  with  regard  to  interjudge  reliability  can  be 
drawn.  Following  discussions  to  reconcile  difference, 
however,  the  two  researchers  attained  100%  agreement. 

d.  Non— value  Added  Activities  Removed 

Prior  to  discussing  their  ratings,  the 
correlation  between  the  two  researchers  on  this  criterion 
is  0.96  indicating  that  significant  agreement  exists. 
Following  discussions,  the  two  researchers  attained  100% 
agreement . 
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e.  Change  in  Number  of  Hand— of fs 

Prior  to  discussing  their  ratings,  the 
correlation  between  the  two  researchers  on  this  criterion 
is  0.84  indicating  that  significant  agreement  exists. 
Following  discussions,  the  two  researchers  attained  100% 
agreement . 


f.  Clarity 

Significant  differences  existed  at  first  between 
the  two  judges  with  regard  to  clarity  (note  the  somewhat 
low  correlation  of  0.53  between  their  two  sets  of  ratings 
prior  to  discussion) .  This  can  be  explained  by  the 
differences  in  techniques  the  two  judges  applied  to  assign 
a  value  this  criterion.  One  researcher  established  a  clear 
set  of  criteria,  as  outlined  above,  which  was  applied  to 
each  redesign  to  determine  what  value  should  be  assigned. 
The  other  researcher  used  a  somewhat  less  systematic,  more 
qualitative  assessment  in  the  assignment  of  clarity  scores. 
Following  discussions  to  reconcile  differences  between  the 
two  researchers'  scores,  100%  agreement  was  attained. 

g.  Impact 

Prior  to  discussing  their  ratings,  the 
correlation  between  the  two  researchers  on  this  criterion 
is  1.0  indicating  that  the  ratings  assigned  by  both 
researchers  matched  exactly. 


Integrated  Analysis 


2. 
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After  reaching  consensus  between  the  two  analyses,  an 
integrated  analysis  was  performed.  First,  a  correlation 


matrix  was  developed  to  see  if  any  pairs  of  criteria  seemed 
to  move  together.  The  results  of  this  analysis  are 
contained  in  the  table  below. 


Correlation 

Matrix 

Redesigns 
per  subject 

Delinearization 

(0=N;1=Y) 

IT  enablers 

Non-IT 

enablers 

non-value 
added  items 
removed 

change  in  #  of 
feedback  loops 

change  in  #of 
hand-offs 

Clarity 

Impact 

Delinearization 

N/A 

XXX 

-0.094011639 

0.519674637 

-0.171789602 

-0.150647456 

-0.129574841 

0.061349982 

0.342864196 

IT  enablers 

N/A 

XXX 

XXX 

-0.045950545 

-0.276677323 

-0.164370749 

-0.315067908 

0.067106949 

0.501988309 

non-IT 

enablers 

N/A 

XXX 

XXX 

XXX 

0.013144741 

-0.141064123 

-0.026438973 

0.242303425 

0.511553536 

Bum 

N/A 

XXX 

XXX 

XXX 

XXX 

0.378130105 

0.648540606 

-0.027253437 

-0.220458969 

feedback  loops 

N/A 

XXX 

XXX 

XXX 

XXX 

XXX 

0.619683511 

-0.128009047 

-0.195219569 

handoffs 

N/A 

XXX 

XXX 

XXX 

XXX 

XXX 

XXX 

-0.162987375 

-0.341127616 

clarity 

N/A 

XXX 

XXX 

XXX 

XXX 

XXX 

XXX 

XXX 

0.395138052 

impact 

N/A 

XXX 

XXX 

XXX 

XXX 

XXX 

XXX 

XXX 

XXX 

Table  3-1.  Correlation  Matrix. 


Numbers  approaching  unity  would  signify  that  the  two 
criteria  move  together;  that  perhaps  they  are  measuring  the 
same  thing.  As  can  be  seen  in  the  table  above,  such  is  not 
the  case  in  this  analysis.  This  provides  evidence  that  the 
eight  criteria  being  looked  at  are  not  redundant  with  one 
another . 

The  next  step  was  to  test  the  null  hypothesis:  "KOPeR- 

lite  does  not  provide  any  significant  benefit  to  novices 

developing  BPR  redesigns."  To  test  this  hypothesis,  the 

data  set  was  first  broken  down  into  four  subsets:  (1) 

Without  KOPeR  Group  (with  outliers),  (2)  Without  KOPeR 

Group  (without  outliers) ,  (3)  With  KOPeR  Group  (with 

outliers),  and  (4)  With  KOPeR  Group  (without  outliers)  . 

"Outliers"  refers  to  the  subjects  who  analyzed  the  baseline 

process  in  a  significantly  different  manner  than  the 

majority  of  subjects.  The  typical  baseline  analysis  broke 
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the  process  down  into  six  activities  with  five  handoffs  and 
two  feedback  loops  as  is  depicted  below. 


Figure  3-2.  Typical  Baseline  Analysis  for  the  Software 
Development  Case  (see  Appendix  A) 

The  arithmetic  mean,  standard  deviation  and  confidence 
intervals  for  each  of  the  metrics  for  the  two  "Without 
KOPeR-lite"  groups  were  then  calculated.  Confidence 

intervals  were  set  at  both  0.95  and  0.90.  Next,  the 
arithmetic  mean  and  standard  deviation  for  each  of  the 
eight  criteria  in  the  two  "With  KOPeR"  groups  were 
calculated.  These  means  were  then  compared  to  the 

confidence  intervals  of  their  respective  "Without  KOPeR" 
sets  to  identify  any  significant  differences.  Where  means 
for  the  "With  KOPeR"  subsets  fell  outside  the  confidence 
intervals  for  the  "Without  KOPeR"  subsets,  we  have  evidence 
that  KOPeR  does  yield  significant  benefit  to  the  BPR 
novices  in  this  experimental  group.  A  textual  summary  of 
the  results  is  provided  below. 
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WIT] 

H  Outliers 

Without 

KOPeR 

With  KOPeR 

95% 

confidence 

Interval 

90% 

confidence 

Interval 

70% 

confidence 

Interval 

#  redesigns  per 
subject 

2.1 

1.94 

Within 

Within 

Delinearizatio 

n 

0.2727 

0.2727 

Within 

Within 

IT  enablers 

3 

3.6363 

Above 

Above 

Above 

Non-IT 

enablers 

.97727 

1.2424 

Within 

Above 

Above 

Non-value 
added  items 
removed 

0.15909 

-1.4545 

Below 

Below 

Below 

Change  in  #  of 
feedback  loops 

-0.3409 

-.57575 

Within 

Within 

Within 

Change  in  #  of 
handoffs 

-1.8409 

-2.7878 

Below 

Below 

Below 

Clarity 

1.6136 

Above 

Above 

Above 

Impact 

1.81818 

Within 

Within 

Within 

Table  3-2a.  Comparison  of  Means  for  the  "With  Outlier" 

Groups . 


WITHOUT  Ou 

t  1  i  e  r  s 

Without 

KOPeR 

With  KOPeR 

95% 

confidence 

Interval 

90% 

confidence 

Interval 

70% 

confidence 

Interval 

#  redesigns  per 
subject 

2.06 

1.93 

Within 

Within 

Below 

Delinearizatio 

n 

0.324324 

0.24137 

Within 

Within 

Below 

IT  enablers 

2.97297 

3.34482 

Within 

Within 

Within 

Non-IT 

enablers 

1.027027 

1.31034 

Within 

Above 

Above 

Non-value 
added  items 
removed 

-0.027027 

-0.20689 

Below 

Below 

Below 

Change  in  #  of 
feedback  loops 

-0.16216 

-0.17241 

Within 

Within 

Within 

Change  in  #  of 
handoffs 

-1.135135 

-1.44827 

Within 

Within  1 

1  Below 

Clarity 

1.567567 

1.89655 

Above 

Above 

Above 

Impact 

1.810810 

1.86206 

Within 

Within 

Within 

Table  3-2b.  Comparison  of  Means  for  the  "Without 

Outlier"  Groups 


For  criteria  where  the  With  KOPeR-lite  group  produced 
superior  results,  the  appropriate  cell  in  tables  3-2a  and 
3-2b  are  lightly  shaded.  For  those  with  no  significant 
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difference,  the  cell  contains  diagonal  hatches  and  those 
where  the  With  KOPeR-lite  group' s  performance  was  inferior, 
the  cell  contains  cross-hatches. 

D .  FINDINGS 

Based  on  the  results  summarize  in  Table  3-2,  several 
differences  between  redesign  performance  of  the  two  subject 
groups  (i.e..  With  and  Without  KOPeR-lite)  are  significant 
and  worthy  of  comment. 

Looking  first  at  the  With-Out liers  (i.e.,  whole) 
Group,  notice  the  KOPeR-lite  group  employed  significantly 
more  IT  enablers  (95%  level)  and  non-IT  enablers  (90% 
level) .  This  KOPeR-lite  group  also  decreased  the  number  of 
handoffs  significantly  (95%  level),  and  the  redesign 
descriptions  of  this  group  were  significantly  clearer  (95% 
level) .  These  are  all  considered  positive  results,  in  that 
such  redesigns  are  generally  considered  superior  according 
to  contemporary  re-engineering  theory. 

Alternatively,  notice  the  number  of  non-value-added 
items  removed  as  significantly  lower  for  the  KOPeR-lite 
group.  Since  non-value-added  items  are,  by  definition,  not 
essential  for  process  performance,  a  superior  redesign 
would  remove  more  such  items,  not  less.  Hence,  the  KOPeR- 
lite  group  appears  to  perform  worse  than  the  control  group 
according  to  this  criterion. 

Notice  the  change  in  number  of  feedback  loops  is  not 
significantly  different  between  the  two  groups  nor  is  the 
difference  in  number  of  redesigns  generated  per  subject. 
Most  surprising  is  that,  despite  the  "superior"  theoretical 
redesign  performance  noted  above,  the  difference  in 
potential  impact  of  redesigns  developed  across  the  two 
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groups  is  also  insignificant.  Thus,  although  the  use  of 
KOPeR-lite  produces  several  differences  that  are  considered 
positive  in  terms  of  re-engineering  theory,  these  empirical 
results  suggest  such  theory  may  require  an  update,  for 
judged  redesign  performance  is  indistinguishable  between 
the  with-  and  without-KOPeR-lite  groups. 

These  results  suggest  that  the  key  benefits  of  using 
KOPeR-lite  stem  principally  from  the  use  of  enablers  and 
clarity  of  redesign  descriptions.  And,  although  the 
reduction  in  process  friction  expected  from  decreasing 
handoffs  in  the  process  should  improve  performance  in  terms 
of  cycle  time,  such  performance  improvement  was  not  judged 
to  be  significant  in  terms  of  redesign  impact. 

Results  of  the  without-out Tiers  groups  are  similar, 
except  that  many  of  the  differences  are  not  as  significant 
between  the  With-  and  Without-KOPeR-lite  Groups  when  they 
are  removed.  For  instance,  the  number  of  IT  enablers  and 
change  in  the  number  of  handoffs  are  considerably  less 
significant  between  these  groups  than  between  the  With- 
Outliers  Groups  as  noted  above.  However,  the  difference  in 
delinearization  between  the  With-  and  Without-KOPeR-lite 
Groups  is  marginally  significant  when  the  outliers  are 
removed.  Consistent  between  the  with-  and  without-out Tiers 
analyses  are  differences  in  non-IT  enablers  used  and 
clarity  of  the  redesigns.  Also  as  above,  differences  in 
impact  between  the  With-  and  Without-KOPeR-lite  Groups  are 
insignificant.  Thus,  some  KOPeR-driven  differences  in 
redesign  performance  noted  above  are  mitigated  when 
outliers  are  removed,  but  the  difference  in  clarity  of 
redesign  descriptions  remains  prominent.  These  findings 


34 


suggest  implications  in  terms  of  KOPeR-lite  use  as 
discussed  below. 

Referring  back  to  the  data  contained  in  Table  3-1, 
there  are  some  correlations  that  warrant  some  discussion. 
For  instance,  the  correlation  between  "change  in  number  of 
handoffs"  and  both  "non-value  added  items  removed"  and 
"change  in  number  of  feedback  loops"  are  0.65  and  0.62 
respectively.  Upon  reflection,  however,  this  intuitively 
makes  sense.  If  you  remove  processes,  the  likelihood  that 
number  of  handoffs  will  be  reduced  it  pretty  high. 
Likewise,  if  you  reduce  the  number  of  handoffs,  there  is  a 
reasonable  chance  that  one  or  more  feedback  loops  may  be 
eliminated. 

Additionally,  the  correlation  between  "Impact"  and 
both  "IT  enablers"  and  "Non-IT  enablers"  are  higher  than 
most  of  the  other  correlations  with  values  of  0.50  and  051 
respectively.  Again,  this  correlation  seems  somewhat 
intuitive:  The  greater  the  number  of  enablers  incorporated 
into  a  process  redesign  the  greater  the  impact  the  redesign 
can  be  expected  to  effect  when  implemented. 


E.  SUMMARY 

The  findings  from  this  experiment  revealed  a  number  of 
anticipated  results  as  well  as  surprises.  We  had 

anticipated  KOPeR-lite  use  to  promote  incorporation  of 
additional  enablers  into  process  redesigns,  for  the  system 
can  augment  a  person's  memory  and  level  of  redesign 
expertise.  For  instance,  where  a  novice  in  terms  of 
process  redesign  may  not  be  aware  of  certain  enablers 
(e.g.,  case  manager,  delinearization),  KOPeR-lite  can 
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suggest  the  use  of  such  enablers  when  its  diagnostics  imply 
they  are  appropriate.  Additionally,  because  KOPeR-lite 
employs  a  consistent,  systematic  approach  to  process 
redesign  (e.g.,  measurement,  diagnosis,  matching),  we 
anticipated  that  redesign  descriptions  would  reflect  some 
of  this  systematic  consistency  in  terms  of  clarity.  These 
can  both  be  viewed  as  positive  benefits  stemming  from 
KOPeR-lite  use. 

Alternatively,  we  were  quite  surprised  that  KOPeR-lite 
did  not  produce  significant  differences  in  terms  of 
potential  impact  of  the  redesigns  generated.  Following  re¬ 
engineering  theory,  we  anticipated  that  incorporation  of 
additional  enablers  as  noted  above  would  lead  to  greater 
impact  in  terms  of  performance  improvement.  Although  the 
impact  associated  with  redesigns  produced  by  the  With- 
KOPeR-lite  Groups  were  indeed  judged  to  be  greater  than 
those  generated  by  the  Without-KOPeR-lite  Groups,  we  found 
no  significant  differences  in  terms  of  this  measure. 

One  explanation  for  this  is  the  relatively  small 
sample  (n  =  44)  employed  in  the  experiment.  It  could  be 
that,  with  more  test  subjects,  the  positive  differences  in 
terms  of  redesign  impact  would  become  significant.  Perhaps 
a  future  study  could  test  this  supposition. 

Another  explanation  could  be  that  the  judges'  criteria 
used  to  score  the  various  redesigns  according  to  this 
criterion  were  flawed.  It  could  be  that,  despite  the 
judges  drawing  from  re-engineering  theory  to  assess  the 
potential  impact  of  various  redesigns,  physical  processes 
redesigned  using  KOPeR-lite  may  indeed  exhibit 
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statistically  significant  performance  improvement.  But 
this  also  remains  for  a  future  study  to  examine. 

A  third  explanation  is,  KOPeR-lite  lacks  the  kind  of 
strong  domain  knowledge  required  to  make  a  significant 
difference  in  terms  of  novices'  redesign  performance.  With 
the  incorporation  of  additional  process  measures, 
diagnostic  tests  and  redesign  rules,  for  instance,  this 
system  may  prove  to  enhance  redesign  performance  in  ways 
the  current  KOPeR-lite  system  cannot.  Examining  this 
possibility  will  require  modification  of  KOPeR-lite  and 
another  experiment  to  assess  the  impact  of  the  modified 
system  on  redesign  performance,  which  as  above,  is  a  matter 
for  a  future  study. 

In  terms  of  the  present  research,  KOPeR-lite  will  be 
used  to  take  advantage  of  the  things  it  does  well  (e.g., 
identifying  enablers,  reducing  handoffs,  clarity  of 
redesign  descriptions) ,  but  the  researcher  will  not  rely 
upon  KOPeR-lite  alone.  Redesign  of  the  Marine  Corps 
process  is  presented  in  the  following  section. 
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IV.  THE  PERSONNEL  ASSIGNMENT  PROCESS  IN  THE  USMC 


A.  DESCRIPTION  OF  THE  CURRENT  PROCESS 

One  process  that  has  been  identified  by  personnel 
management  experts  in  the  Marine  Corps  as  problematic  is 
the  permanent  change  of  station  (PCS)  orders  process  for 
officers,  particularly  after  their  first  tour  of  duty. 
This  problem  has  been  articulated  by  not  only  individuals 
who  participate  in  the  planning  and  assignment  process,  but 
also  by  the  people  who's  lives  and  careers  are  most 
prominently  affected  by  how  well  (or  poorly)  the  process  is 
carried  out.  Problems  include  numerous  databases  that 
capture  various  subsets  of  information  where  these 
databases  are  loosely,  if  at  all,  integrated.  As  a  result, 
the  information  contained  in  various  reports  generated  by 
tapping  into  the  databases  does  not  reflect  an  accurate 
picture  of  the  current  manning  situation.  Numerous  issues 
plague  officers  who  are  due  for  orders.  Two  of  the  most 
common  complaints  are  with  regard  to  the  timeliness  with 
which  they  are  issued  orders  and  the  inability  of 
individual  officers  to  access  a  list  of  current  and 
projected  billet  vacancies  so  that  they  can  more  precisely 
articulate  their  desires  for  future  assignment s^ . 

Before  we  can  consider  how  and  when  individuals  are 
issued  PCS  orders,  we  must  first  understand  the  Marine 
Corps  underlying  framework  for  manpower  management.  Table 
of  organizations  (T/O's)  are  established  for  all  units. 
T/O's  are  listings  of  all  the  jobs  associated  with  a 

^  The  U.S.  Air  Force  has  a  mechanism  in  place  where  all  officers  can 
access  a  current  list  of  available  billets  and  communicate  directly 
with  the  individual  or  department  responsible  for  making  future 
assignments . 
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particular  command.  Information  contained  on  a  T/0 
includes:  T/0  number,  billet  line  number,  billet  rank,  and 
billet  description. 

Each  unit  is  then  assigned  a  staffing  priority  level. 
These  levels  are:  (1)  V-unit,  which  are  units  that 
consistently  maintain  a  high  state  of  readiness  so  that 
they  may  deploy  at  a  moment's  notice,  (2)  priority,  (3) 
excepted,  which  include  joint  billets  and  other  critical 
billets,  and  (4)  all  others.  V-units  are  staffed  at  100% 
of  their  authorized  strength.  Priority  commands  are 
staffed  at  95%,  excepted  commands  at  99%,  and  all  others  at 
80%. 

Another  source  of  information  used  in  managing 
personnel  is  the  Marine  Corps  Total  Force  System  (MCTFS) . 
This  database  contains  personal  information  about  each  and 
every  Marine.  Included  are  such  items  as:  name,  social 
security  number,  date  of  birth,  rank,  date  of  rank,  current 
address,  phone  number,  record  of  emergency  data 
information,  blood  type;  training  information  such  as 
rifle,  pistol,  swim  qualifications,  current  physical 
fitness  test  (PFT)  results,  primary  and  secondary  military 
occupational  specialty  codes;  uniform  size  information  for 
such  things  as  gas  mask,  camouflage  blouse,  camouflage 
trousers;  and  current  tour  information  such  as  T/0  number, 
line  number,  billet  rank,  billet  name,  billet  MOS,  and  date 
current  tour  began  among  others.  For  the  purposes  of  this 
chapter,  the  personal  information  and  current  tour 
information  will  be  of  primary  importance. 

Based  on  the  information  contained  in  T/O's, 
established  staffing  goals,  and  MCTFS,  a  Personnel 


40 


Management  Report^  (PMR)  is  generated.  One  of  the  uses  of 
this  report  is  to  plan  future  personnel  assignments. 

In  order  to  determine  future  assignments,  the 
following  are  key  elements  of  information: 

•  what  billets  are  to  be  staffed, 

•  which  of  these  billets  are  currently  vacant,  and 

•  when  individuals  are  projected  to  rotate  out  of 

their  current  assignment.  (This  can  be 

calculated  by  adding  the  appropriate  tour  length 
to  an  individual's  "date  current  tour  began" 
(DCTB)  entry  contained  in  MCTFS . ) 

A  tour  of  duty  is  generally  three  years  in  length  of 
assignments  within  the  continental  United  States  (CONUS) 
and  outside  of  the  continental  United  States  (OCONUS) 
accompanied  tours,  and  one  year  for  OCONUS  unaccompanied 
tours.  Though  the  process  is  essentially  the  same 

regardless  of  tour  length  or  location,  for  simplicity,  THE 
focus  is  on  three  year  CONUS  or  accompanied  OCONUS  tours 
for  the  remainder  of  this  section. 

Once  an  individual  has  spent  two  years  in  their 
current  assignment,  they  have  fulfilled  the  obligated 
service  requirement  incurred  for  their  most  recent  CONUS 
PCS  move.  HQMC  can,  therefore,  begin  considering  them  for 
a  future  assignment  though  their  goal  is  for  individuals  to 
serve  three  years  in  their  current  assignment  before 
ordering  them  to  report  to  a  new  command.  However,  since 


^  The  PMR  is  a  reporting  mechanism  developed  by  a  gentleman  named  Mr. 
Marsh  back  in  approximately  1966.  It  reports  such  information  as  the 
current  personnel  inventory,  proper  staffing  inventory  (which  si  driven 
by  such  factors  as  yearly  authorized  strength,  yearly  on  hand  strength, 
T/0  allowance,  and  T/0  staffing  goal,  as  well  as  individual's  rank, 
MOS,  etc..  It  is  connected  to  MCTFS  only  at  the  front-  and  back-ends, 
but  doesn't  directly  interact  with  MCTFS.  For  instance,  information 
about  a  person  on  the  PMR  will  not  "trigger"  a  move  in  MCTFS. 
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their  service  obligation  has  been  fulfilled,  these 
individuals  are  referred  to  as  "movers." 

In  the  orders  process,  there  are  four  primary 
stakeholders.  These  are  the  "mover,"  monitors^,  as  well  as 
the  losing  and  gaining  commands. 

At  about  the  two-year  mark,  the  mover  has  the  option 
of  communicating  his  or  her  follow-on  assignment 
preferences  to  his  or  her  respective  monitor.  Future  duty 
preferences  can  be  communicated  to  the  monitor  in  any 
number  of  ways,  to  include: 

•  the  duty  preference  codes  listed  by  an  individual 
on  their  performance  evaluations  (these 
eventually  get  reported  into  the  MCTFS) ; 

•  submitting  duty  preference  via  the  website 

maintained  by  the  Manpower  Management  Officer 
Assignment  (MMOA)  branch  (a  standalone  database 
accessible  only  by  MMOA  staff  and  individuals 
updating  their  personal  record)  ; 

•  email  or  telephone  communications  between  the 

monitor  and  individual  officer,  or 

•  conversations  held  when  the  monitor  and 

individual  officers  are  able  to  meet  in  person 

(such  as  during  MMOA' s  annual  "road  show"  where 
all  the  monitors  visit  the  major  installations 
with  the  primary  intent  of  meeting  with  and 
discussing  future  assignments  with  individuals 
who  are  nearing  the  end  of  their  current  tour) . 

Note  that  only  one  of  these  methods  (the  listing  of 

duty  preference  codes  on  one's  performance  evaluation) 


^  Monitors  are  individuals  working  in  the  HQMC,  Manpower  and  Reserve 
Affairs,  Manpower  Management  [MRA  (MM)]  section  that  manage  personnel 
assigned  the  military  occupational  specialties  (MOS's)  they've  been 
assigned  to  manage.  They  must  match  officer  desires  with  needs  of  the 
Corps  in  the  short  run,  but  also  to  ensure  that  a  sufficient  number  of 
officers  are  trained,  experienced,  and  qualified  to  command  and  staff 
the  Corps  in  the  future. 
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results  in  an  update  to  the  information  contained  in  MCTFS, 
the  database  used  to  generate  the  PMR. 

Currently,  the  mover  does  not  have  access  to 
information  about  which  billets  are  vacant  or  due  to  become 
vacant.  Only  the  monitor  has  access  to  this  information. 

Armed  with  a  list  of  movers,  the  movers'  preferences, 
and  a  list  of  current  and  projected  billet  vacancies,  the 
monitor  begins  the  process  of  identifying  which  individuals 
will  be  assigned  to  current  and  upcoming  billet  vacancies. 
The  monitor  must  apply  the  criteria  outlined  in  MCO 
P1300.8G  Ch  4  in  determining  future  assignments. 

•  needs  of  the  Marine  Corps, 

•  MOS/Billet  variety^, 

•  Availability  of  the  individual, 

•  Overseas  control  date  (OCD) 

•  Seniority^,  and 

•  Individual  preferences. 


^  Monitors  take  care  to  ensure  officers  have  the  opportunity  to 
perform  in  their  MOS  including  command  at  the  junior  ranks,  and  in 
other  staff  and  instructor  billets,  as  well  as  have  the  opportunity  to 
attend  appropriate  military  education,  to  ensure  they  are  "fully 
qualified."  Needs  of  the  Corps  also  demand  officers  be  assigned  to 
recruiting,  instructor.  Marine  Corps  Security  Force,  Marine  Corps 
Recruit  Depot,  acquisition,  joint,  and  Navy  staff  duty. 

®  The  Overseas  Control  Date  (OCD,  or  OSCD  on  the  Master  Brief  Sheet) 
remains  a  fair  way  to  determine  an  officer's  place  in  the  "queue."  The 
OCD  may  take  precedence  over  other  assignment  factors  considered  by  the 
monitor.  The  monitor  will  determine  the  number  of  overseas  "fills" 
required  by  MOS,  and  compare  that  to  officers'  OCD.  The  older  the 
officer  OCD,  the  more  likely  the  assignment  to  an  overseas  tour. 

An  officer's  seniority  must  be  taken  into  account  to  lessen  the 
possibility  they  will  not  be  promoted  out  of  the  assignment  prior  to 
completing  the  prescribed  tour  length. 

8  Note  that  individual  preference  is  the  last  criteria  applied  when 
the  monitor  makes  assignments. 
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In  addition  to  the  criteria  outlined  in  P1300.8G  Ch  4 


the  monitor  must  also  take  into  account  the  following 
criteria  outlined  in  MMOA' s  Officer  Development  Handbook: 

•  Staffing  Goal® 

•  Authorized  Strength  Report  (ASR) 

•  Time  in  geographic  location^^  and 

12 

•  An  officer' s  availability  . 

Per  MMOA' s  Officer  Development  Handbook: 

9  The  Staffing  Goal  is  the  "best"  distribution  of  available  Marines 
to  all  authorized  billets.  Each  year,  a  computer  Staffing  Goal  Model  is 
run  to  produce  a  preliminary  "fit"  of  available  officers  by  grade  and 
PMOS  to  authorized  billets.  MMOA's  staffing  goal  model  combines  those 
billets  that  CG,  MCCDC  has  authorized  to  be  manned  with  the  available 
officer  inventory.  Monitors  manually  review  the  model  and  make 
necessary  changes. 

10  The  Authorized  Strength  Report  (ASR)  is  a  CG,  MCCDC  (TFSD) 

document  produced  semi-annually  which  completes  the  manning  process. 

The  ASR  converts  the  macro  Troop  List  manning  numbers  into  the  micro 
level  of  detail.  Specifically,  the  ASR  allocates  manning  to  units 
(MCCs)  by  grade  and  MOS .  Remember,  manning  is  about  billets,  not 
people.  Through  the  manning  process,  the  Marine  Corps  is  "buying"  xxx 
number  of  billets.  TFSD  then  determines  what  percent  of  those 
authorized  billets  are  actually  filled.  The  ASR  is  the  linking  document 
between  MCCDC  and  M&RA.  The  ASR  is  delivered  to  MM  Division  for  use  in 
the  staffing  goal  models  (the  staffing  process-distribute  current 
inventory)  and  MR  Division  for  input  into  the  GAR  (the  development 

manpower  plans  process-build  future  inventory) . 

11  Three  years  has  long  been  the  standard  tour  length.  ALMAR  075/96 

of  4  Mar  96,  Increasing  the  Number  of  4  to  5-Year  geographic  location 
tours,  outlined  the  "standard"  3-year  policy,  and  published  the  CMC '  s 
guidance  for  4  to  5-year  tours,  and  the  analysis  by  the  1995  General 

Officer  Symposium.  The  consensus  of  the  Corps'  senior  leaders  indicated 

that  an  increase  in  the  number  of  4  to5-year  geographic  location  tours 
would  benefit  both  the  Corps  and  the  individual  Marine  by  increasing 
unit  stability,  reducing  family  turbulence  and  reducing  PCS  costs.  The 
CMC  approved  the  General  Officer  Symposium  recommendation  and  directed 
that  the  number  of  4  to  5-year  geographic  location  tours  be  increased 
whenever  the  needs  of  the  Corps  and  individual  preferences  can  be 
accommodated  by  the  longer  tour.  Extended  tours  would  include  extension 
on  station  with  the  same  command,  split  tours  between  commands  at  the 
same  installation,  and  low  cost  PCS  and  PCA  orders  between  commands  in 
the  same  geographic  location.  While  this  change  is  a  clear  move  toward 
an  increase  in  tour  length,  it  is  not  a  guarantee  that  all  Marines  will 
serve  4  to  5  years  at  the  same  command  or  in  a  particular  geographic 
location.  Officers  interested  in  remaining  in  place  for  longer  tours  of 
duty  should  inform  their  monitor. 

An  officer's  availability  will  depend  on  prescribed  tour  lengths, 
internal  and  external  billet  requirements,  and  allowable  exceptions  to 
assignment  policy.  Obviously,  monitors  must  minimize  the  number  of 
assignments  that  require  tour  length  waivers. 
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Once  a  monitor  has  a  potential  officer  for  an 
assignment,  the  assignment  enters  an  approval 
process  that  varies  with  type  and  grade. 

A  company  grade  monitor's  potential  assignment 
for  a  warrant  officer,  chief  warrant  officer, 
lieutenant,  or  captain  is  reviewed  by  a  "center 
desk"  major  as  a  quality  assurance  check  and 
approval.  If  the  assignment  requires  a  waiver  of 
policy,  it  is  reviewed  by  the  aviation  or  ground 
section  head  (a  lieutenant  colonel) ,  and  then  can 
be  approved  by  the  Officer  Assignment  Branch  Head 
(a  colonel) .  If  the  assignment  involves  a  move  at 
2  years  or  less,  the  Personnel  Management 
Division  Director  (a  major  general)  reviews  it. 

If  the  assignment  is  to  a  joint  or  acquisition 
billet,  the  Joint  Officer  Management  Officer  or 
Acquisition  Management  Officer  reviews  the 
assignment  and  provides  a  recommendation  to  the 
Officer  Assignment  Branch  Head. 

A  field  grade  officer's  assignment  is  reviewed  by 
the  Aviation  or  Ground  Monitor  Section  Head  (a 
lieutenant  colonel) ,  by  the  aviation  or  ground 
colonel's  monitor  (a  colonel),  and  by  the  Officer 
Assignment  Branch  Head  (a  colonel) .  If  the 
assignment  is  to  a  joint  or  acquisition  billet, 
the  Joint  Officer  Management  Officer  or 
Acquisition  Management  Officer  reviews  the 
assignment  and  provides  a  recommendation  to  the 
Officer  Assignment  Branch  Head.  The  Branch  Head 
makes  a  recommendation  to  the  Personnel 
Management  Division  Director  (a  major  general) 

Once  the  assignment  proposed  by  the  monitor  has  be 
approved,  the  monitor  then  issues  orders^^. 

Unlike  with  orders  for  enlisted  services  members  which 
are  issued  using  the  Automated  Order  Writing  Process 


Orders  are  the  authoritative  document  that  tells  the  mover:  (1) 
when  he  or  she  is  to  detach  from  their  currently  command,  (2)  what 
command  he  or  she  is  to  report  to  (3)  when  he  or  she  is  to  report  to 
their  future  command,  (4)  and  under  what  set  of  appropriation  data  the 
orders  are  to  be  executed. 
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System (AOWPS)  orders  for  officers  can  be  issued  using  any 
number  of  ways,  to  include:  (1)  AOWPS,  (2)  verbal  or 

telephonic  (these  are  eventually  backed  up  by  written 
orders  of  some  type),  (3)  e-mail,  (4)  FAX,  (5)  Defense 
Message  Service  (DMS) ,  (6)  letter-type.  Of  these  methods, 
only  the  first  results  automatically  updating  the 
information  contained  in  MCTFS .  For  all  other  methods  of 
issuing  orders,  MCTFS  must  be  manually  updated,  either  by 
HQMC  prior  to  the  officer' s  detaching  date  or  by  the 
receiving  command  once  he  or  she  reports  in. 


The  potential  delay  in  updating  the  information 
contained  in  MCTFS  poses  some  problems.  Until  MCTFS  is 
updated,  the  information  contained  in  the  PMR  will  not  be 
accurate.  If  the  PMR  is  inaccurate,  the  effectiveness  of 
that  report  as  a  planning  tool  is  greatly  diminished.  If 
the  PMR  is  inaccurate,  the  staffing  goal  model  used  in  the 
Manpower  Management  section  at  HQMC  will  not  portray  an 
accurate  picture. 


Three  years  has  long  been  the  standard  tour  length.  ALMAR  075/96 
of  4  Mar  96,  Increasing  the  Number  of  4  to  5-Year  geographic  location 
tours,  outlined  the  "standard"  3-year  policy,  and  published  the  CMC '  s 
guidance  for  4  to  5-year  tours,  and  the  analysis  by  the  1995  General 
Officer  Symposium.  The  consensus  of  the  Corps'  senior  leaders  indicated 
that  an  increase  in  the  number  of  4  to5-year  geographic  location  tours 
would  benefit  both  the  Corps  and  the  individual  Marine  by  increasing 
unit  stability,  reducing  family  turbulence  and  reducing  PCS  costs.  The 
CMC  approved  the  General  Officer  Symposium  recommendation  and  directed 
that  the  number  of  4  to  5-year  geographic  location  tours  be  increased 
whenever  the  needs  of  the  Corps  and  individual  preferences  can  be 
accommodated  by  the  longer  tour.  Extended  tours  would  include  extension 
on  station  with  the  same  command,  split  tours  between  commands  at  the 
same  installation,  and  low  cost  PCS  and  PCA  orders  between  commands  in 
the  same  geographic  location.  While  this  change  is  a  clear  move  toward 
an  increase  in  tour  length,  it  is  not  a  guarantee  that  all  Marines  will 
serve  4  to  5  years  at  the  same  command  or  in  a  particular  geographic 
location.  Officers  interested  in  remaining  in  place  for  longer  tours  of 
duty  should  inform  their  monitor. Per  MCO  P1000.8,  par  1201.4,  "The 
Automated  Orders  Writing  Process  (AOWP)  ...is  designed  to  allow  HQMC  to 
forward  PCS  orders  data  to  a  Marine's  command  via  MCTFS.  AOWP  is  the 
primary  method  of  issuing  orders  for  enlisted  Marines."  No  such 
standard  exists  for  issuing  orders  to  officers. 
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The  process  discussed  above  can  be  roughly  distilled 
into  the  activities  pictured  below: 

A  process  representation  is  provided  below  and  a 
textual  description  follows: 


ACTIVITITES 

A 
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B, 

B2 

Bj 

C 

ATTRIBUTES 

0:15 
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Orders 
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Mover  and 
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Order 

Approval 
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Monitor 
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Supervisor 
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•PMR* 
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• 

MCTFS 

• 
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•PMR* 

•PMR 

•  telephone 
•FAX 
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•FAX 

• 
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*  The  PMR  is  software  tool  that  generates  a  report  having  the  same 

name . 


15  MQii  designates  the  performing  organization  in  the  process  (e.g.. 
Sales  Department,  Requirements  Department) 

16  designates  the  agent  role  in  the  process  (e.g..  Sales  Agent, 
Requirements  Agent) 

"S"  designates  the  information  technology  employed  for  support  in 
the  process  (e.g.,  word  processor  (WP) ,  computer-aided  software 
engineering  (CASE)  tool) 

18  iiQM  designates  the  media/technology  employed  for  communication  in 
the  process  (e.g.,  phone,  report) 
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Figure  4-1.  Baseline  Orders  Process  for  USMC  Officers 


•  Activity  "A":  This  activity  includes  producing 

and  maintaining  the  T/O's,  running  the  PMR  tool 
to  generate  the  PMR,  and  determining  a  staffing 
priority  each  command  (e.g.,  V-unit,  priority, 
etc);  essentially,  all  the  high  level  activities. 

•  Activity  "B" :  This  is  where  the  "rubber  meets 

the  road."  Monitors  set  about  determine  who  will 
be  moving  and  when,  what  billets  are  or  will  need 
to  be  filled,  apply  the  various  criteria  outlined 
by  both  MOO  P1300.8G  and  the  Officer's 

Development  Handbook,  propose  assignments,  and 
get  approval  for  these  proposals.  If  the 

proposal  is  not  approved,  the  monitor  set  about 
modifying  the  proposal  to  satisfy  the 
requirements  articulated  by  his  or  her 

supervisor . 

•  Activity  "C" :  This  is  where  the  mover  discovers 

how  well  the  process  works.  The  monitor 

disseminates  the  orders.  MCTFS  is  updated 

(either  automatically  or  by  hand  depending  on  the 
method  used  to  disseminate  the  orders) .  Once  the 
mover  receives  his  or  her  orders,  if  there  is 
some  problem  with  the  assignment  or 

detachment /reporting  dates,  the  mover  can 

communicate  with  his  or  her  monitor  to  get  the 
orders  modified  to  better  meet  his  or  her  needs. 
With  the  orders  issued,  mover  in  receipt  of  the 
orders,  and  MCTFS  updated,  the  process  can  begin 
anew . 

Having  completed  an  analysis  of  the  baseline  process, 
the  metrics  contained  in  Figure  4-1  were  inputted  to  KOPeR- 
lite.  The  recommendations  generated  by  KOPeR-lite  are 
contained  in  Appendix  C.  Explanations  of  KOPeR-lite' s 
Redesign  Recommendations  are  contained  in  Appendix  D. 
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Using  these  recommendations  as  a  point  of  departure,  two 
redesign  alternatives  are  provided  below. 

B.  PROPOSED  REDESIGN  ALTERNATIVES 

As  it  indicated  in  Appendix  C,  KOPeR-lite  identifies 
three  areas  that  exhibit  process  pathologies.  These  are 
parallelism,  process  friction  (due  to  a  high  activity  to 
handoff  ratio) ,  and  the  process  friction  generated  by 
excessive  feedback  loops  (checking  and  complexity  in  KOPeR- 
lite  terms) . 

With  regard  to  parallelism,  each  activity  is  dependent 
on  the  output  of  the  activity  preceding  it.  Therefore,  no 
recommendations  are  provided  for  process  delinearization. 
The  focus  of  the  redesigns  proposed  below,  therefore,  will 
be  on  reducing  process  friction  and  increasing  IT 
automation . 

The  focus  of  the  first  redesign  is  to  propose  changes 
requiring  minimal  capital  outlays,  but  still  yield  positive 
results.  A  more  "radical  redesign"  is  proposed  in  the 
second  alternative.  The  costs  of  implementing  some  of  the 
recommendations  could  prove  prohibitive,  but  the  resulting 
impact  will  be  far  greater  than  what  could  be  achieved  by 
implementing  the  recommendations  made  in  the  first 
alternative . 

1 .  Redesign  Alternative  #1 

One  of  major  areas  of  dissatisfaction  from  the  mover's 
standpoint  is  the  small  amount  of  influence  he  or  she  has 
over  their  next  assignment.  This  is  due,  in  part,  to  the 
amount  of  information  made  available  to  the  mover  with 
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regard  to  current  and  projected  billet  vacancies.  To  solve 
this  problem,  one  recommendation  would  be  that  information 
about  current  and  projected  billet  vacancies  used  by  the 
monitors  be  made  available  to  movers.  This  information 
could  be  made  available  by  posting  it  to  a  website.  Movers 
would  continue  to  communicate  their  desires  using  the  same 
communication  channels  present  in  the  baseline  process. 

Empowering  monitors  to  issue  orders  without  explicit 
supervisory  approval  could  reduce  process  friction. 
Proposed  orders  could  be  issued  to  supervisors  where  they 
would  be  given  a  certain  amount  of  time  to  review  them. 
During  this  review  period,  supervisors  would  have  the 
opportunity  to  request  a  modification  to  the  proposal. 
Once  the  review  period  elapses,  the  monitor  would  be 
allowed  to  disseminate  the  orders  without  further  adieu. 

Other  problems  relate  to  the  order  issuance  activity. 
These  stem  from  the  numerous  methods  used  to  disseminate 
PCS  orders  to  officers.  Since  only  one  method,  AWOPS, 
automatically  updates  the  information  contained  in  MOTES, 
it  is  recommended  that  orders  only  be  issued  using  this 
method.  This  will  result  in  MOTES  containing  more 
accurate,  timely  information,  which  will  ultimately  provide 
planners  with  better  information  to  use  during  the  planning 
phase  of  the  orders  process. 

The  figure  below  outlines  the  changes  proposed  above: 
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Figure  4-2.  Alternative  #1  Modified  PCS  Orders 


Process 


2 .  Redesign  Alternative  #2 

As  was  recommended  in  the  first  alternative,  movers 
should  be  given  access  to  information  about  current  and 
projected  billet  vacancies.  This  could  be  accomplished  by 
making  this  information  available  on  a  website.  Movers 
could  then  input  their  billet  preferences  in  an  online 
form.  A  message  would  be  automatically  sent  to  the 
appropriate  monitors  who  could  then  use  this  information  to 
assign  the  officer  to  a  billet  that  most  closely  matches 
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the  mover's  professional  and  personal  needs/desires.  This 
should  result  in  greater  satisfaction  on  the  part  of  the 
mover  once  he  or  she  receives  orders  and  should  eliminate 
the  feedback  loop  between  the  "orders  issuance"  and 
"mapping  of  mover  to  billet"  activities  in  all  but 
exceptional  cases. 

In  terms  of  IT  automation,  a  system  could  be  developed 
whereby  orders  are  automatically  issued  once  the  supervisor 
approves  the  PCS  order  proposals  submitted  by  monitors. 
For  instance,  the  proposal  could  be  forwarded  to  the 
supervisor  using  a  groupware  application  like  LotusNotes. 
Once  approved,  a  middleware  application  could  then  transfer 
the  information  contained  in  LotusNote  to  AWOPS  so  that 
orders  can  be  generated  and  MCTFS  updated.  This  would  be  a 
significant  improvement  over  the  baseline  process  since  one 
feedback  loop  would  be  eliminated  and  a  manual  orders 
generation  process  would  be  eliminated.  This  would  both 
decrease  process  friction  and  increase  process  efficiency. 

An  alternative  method  for  decreasing  the  friction 
present  would  be  to  empower  the  monitors.  The  first 
alternative  still  involves  submitting  proposed  orders  to 
supervisors  for  review.  Perhaps  a  study  should  be 
conducted  to  determine  if  this  review  activity  offers  any 
added  value.  If  there  is  no  value  added,  the  review 
activity  should  be  eliminated.  This  would  decrease  process 
friction  both  in  terms  of  handoffs  and  feedback  loops. 

Additionally,  a  single  means  of  orders  dissemination 
should  be  used.  Instead  of  receiving  orders  in  any  of  the 
six  methods  used  in  the  baseline  process,  one  standard 
method  should  be  adopted,  such  as  the  AWOP  system.  The  key 
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point  here  being  that  the  method  used  should  generate 
automatic  system  updates  so  that  the  information  contained 
in  MCTFS  is  accurate  (which  will  result  in  a  more  accurate 
PMR)  . 
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Figure  4-3.  Alternative  #2  Modified  PCS  Orders  Process 
Note  the  elimination  of  the  supervisory  review  activity 
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V. 


SUMMARY,  CONCLUSIONS,  AND  FUTURE  RESEARCH 


A.  SUMMARY 

This  thesis  showed,  through  a  process  of  statistical 
analysis  and  qualitative  assessment,  the  viability  of  using 
automated  tools,  such  as  KOPeR-lite,  when  undertaking 
process  reengineering  projects.  Additionally, 
reengineering  solutions  for  the  permanent  change  of  station 
orders  process  for  USMC  officers  were  developed  using  a 
combination  of  the  recommendations  generated  by  KOPeR-lite 
and  personal  insight.  These  redesigns  will  be  made 
available  to  the  leadership  in  the  Headquarter,  U.S.  Marine 
Corps  (HQMC)  Manpower  and  Reserve  Affairs  (M&RA)  branch  for 
review  and  possible  adaptation  as  this  branch  moves  to 
implement  the  Defense  Integrated  Military  Human  Resource 
System  (DIMHRS) .  One  of  the  proposed  solutions  may 
dramatically  improve  process  performance. 

Chapter  I  establishes  the  need  for  research  and 
outlines  the  questions  to  be  answered.  Chapter  II  provides 
a  brief  historical  outline  of  process  reengineering  and  why 
it  is  pursued.  Additionally,  the  Davenport  framework  is 
presented  along  with  a  functional  description  of  KOPeR- 
lite.  KOPeR-lite  is  used  to  depict  processes  and  gain  an 
understanding  for  redesign.  Chapter  III  covers  the 
experimental  design,  data,  analysis,  results  and 
implications.  Chapter  IV  addresses  the  matter  of 
reengineering  the  permanent  change  of  station  (PCS)  orders 
process  for  USMC  officers.  It  provides  a  description  of 
the  fundamental  baseline  process,  recommendations  generated 
by  KOPeR-lite  for  process  redesign,  as  well  as  proposed 
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process  redesigns  developed  using  the  KOPeR-lite' s 
recommendations  as  a  point  of  departure.  Chapter  V 
provides  conclusions,  recommendations  and  topics  for 
further  research,  which  are  presented  below. 

B.  CONCLUSIONS 

Redesigns  generated  by  BPR  novices  who  use  KOPeR-lite 
to  aide  them  in  their  reengineering  efforts  are  superior  in 
terms  of  process  enablers  (IT  and  non-IT),  reduced  process 
friction  through  a  reduction  in  handoffs,  and  redesign 
clarity  to  those  produced  by  novices  working  alone.  This 
statement  is  supported  by  the  analysis  discussed  in  Chapter 

III . 

In  light  of  the  benefit  KOPeR-lite  provides,  a  new 
process  was  selected  for  modification;  the  permanent  change 
of  station  orders  process  for  USMC  officers.  This  process 
was  analyzed  in  much  the  same  way  as  the  process  contained 
in  Appendix  A.  The  metrics  were  inputted  into  KOPeR-lite 
and  the  resulting  redesign  recommendations  were  used  as  a 
point  of  departure  for  the  redesigns  proposed  in  Chapter 

IV.  Subsequent  analysis  of  these  redesigns  using  KOPeR- 
lite  show  that  each  of  the  proposed  alternatives  solve  some 
of  the  pathologies  associated  with  the  baseline  process. 
Each  of  the  alternatives  has  been  analyzed  by  KOPeR-lite 
and  the  results  it  its  analysis  are  contained  in  Appendix 

C. 

C .  RECOMMENDATIONS 

Individuals  who  are  tasked  with  reengineering  business 
process  who  have  little  or  no  experience  in  the  field  of 
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BPR,  should  consider  using  KOPeR-lite  or  a  similar  tool  to 
assist  them.  The  recommendations  such  tools  generate 
provide  an  excellent  foundation  on  which  they  can  develop 
process  redesigns. 

Additionally,  HQMC,  M&RA  should  take  steps  to  modify 
the  current  processes  followed  for  managing  the  officer 
corps  in  general  and  the  PCS  orders  process  specifically. 
The  ideas  that  compose  the  alternatives  proposed  in  Chapter 
IV  should  be  considered  for  incorporation  when  this  process 
is  redesigned. 


D .  FUTURE  RESEARCH 

KOPeR-lite  in  its  current  form,  is  only  designed  to 
assist  in  reengineering  knowledge-based  processes. 
Therefore,  one  area  which  warrants  additional  is  to  expand 
the  rule  set  employed  by  KOPeR-lite  so  that  it  can  provide 
redesign  recommendations  for  process  belonging  to  other 
domains . 

A  more  rigorous  statistical  analysis  should  be 
conducted  on  the  data  collected  from  this  initial 
experiment . 

Additional  experiments  should  be  conducted  which  build 
upon  the  one  analyzed  in  Chapter  III.  Follow-on 
experiments  should  focus  on  expanding  the  pool  of 
experimental  subjects.  Included  in  this  pool  of 
experimental  subjects  should  be  working  professionals 
outside  the  military.  Subjects  should  also  represent  a 
broader  range  of  educational  backgrounds.  By  expanding  the 
pool  of  subjects,  the  results  of  subsequent  statistical 
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analyses  can  be  more  easily  generalized  to  the  population 
at  large. 
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APPENDIX  A.  DR.  MARK'S  SOFTWARE  DEVELOPMENT  CASEi® 


This  minicase  centers  around  a  generic  software 
development  process,  the  baseline  of  which  is  described 
below.  First  a  narrative  description  of  the  case  is 
provided.  This  is  followed  by  a  high-level  process  model 
used  to  obtain  measurements.  The  measurements  can  be  used 
in  turn  for  KOPeR  analysis. 


A.  BASELINE  PROCESS 

A  major  service  provider  has  a  separate  organizational 
unit  that  is  responsible  for  the  development  of  large 
software  applications.  Software  development  represents  a 
key  sub  process  in  support  of  both  front-  and  back-office 
operations,  as  the  ability  to  seamlessly  integrate 

marketing  and  sales  with  order  fulfillment  and  product 
support  represents  a  strong  selling  point  for  the  company. 
However,  customer  feedback  has  suggested  that  the  process 
has  a  number  of  shortcomings  and  flaws,  particularly  with 
respect  to  the  long  cycle  time  required  to  prepare  a 

software  application  and  the  inability  to  report  on  the 
status  of  a  particular  package  while  it  is  being  processed. 
A  closer  examination  of  the  process  flow  activities  should 
help  elucidate  some  of  these  shortcomings  and  flaws. 

The  process  involves  three  Value  Stream  participants: 

This  mini  case  was  written  by  Professor  Mark  Nissen 
(http://web.nps.navy.mil/~menissen),  initially  for  his  Electronic 
Commerce  course  at  UC  Berkeley,  and  is  now  used  in  a  number  of  graduate 
courses  at  the  Naval  Postgraduate  School.  It  represents  an 

amalgamation  of  many  software  development  processes,  as  opposed  to  any 
one  particular  case,  with  the  express  purpose  of  promoting  class 
discussion  about  process  redesign.  This  mini  case  may  be  used  for 
instructional  purposes  without  fee,  but  must  be  cited  in  any  academic 
works . 
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1)  Field  Sales  groups  with  representatives  that  work 
to  identify  new  customer  requirements, 

2)  the  software  development  organization,  and 

3)  a  third  party  software  validation  company. 

The  software  development  organization  is  organized  in 
terms  of  four  functional  departments,  each  of  which  is 
staffed  with  specialists  for  the  functional  areas: 

1)  requirements, 

2)  design, 

3)  coding,  and 

4)  test. 

A  process  representation  is  presented  below. 


Test 


From  the  figure  you  can  observe  that  the  process  flow 
is  sequential,  beginning  with  a  telephone  call  from  the 
field  sales  representative  to  the  requirements  manager  in 
the  software  unit.  This  functional  manager  writes  the 
customer-requirements  information  on  a  piece  of  paper  and 
assigns  the  job  to  a  requirements  specialist  from  the 
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department.  This  assignment  is  accomplished  simply  by 
placing  the  paper  in  the  specialist's  in-box.  The 
requirements  specialist  retrieves  the  paper  from  his  or  her 
in-box,  and  begins  to  integrate  the  requirements  of  the 
potential  customer  into  the  functionality  of  the  firm's 
existing  software.  This  integration  is  accomplished 
manually,  but  the  agent  creates  a  requirements  document 
using  a  word  processing  application  on  a  standalone 
computer  terminal  in  the  specialist's  office. 

Once  the  requirements  specialist  completes  the 
requirements  document,  he  or  she  reviews  the  results  with 
the  department  manager.  Upon  approval,  the  paperwork  is 
then  mailed  to  the  Design  Department,  where  another 
functional  manager  will  assign  a  design  specialist  to  work 
on  the  job.  The  design  specialist  in  turn  will  retrieve 
the  requirements  document  from  an  in-box  and  design  the 
software  using  a  CASE  tool  on  a  standalone  workstation  in 
the  specialist's  office.  Once  developed,  the  logical 
design  is  reviewed  with  the  design  manager.  Upon  approval, 
the  design  documentation  is  printed  and  mailed  to  the 
Coding  Department,  where  another  functional  manager 
similarly  assigns  the  job  to  a  coding  specialist  and  places 
the  paperwork  in  the  appropriate  in-box. 

The  coding  specialist  is  responsible  for  implementing 
the  software  through  programming  code.  A  rapid  application 
development  (RAD)  tool  suite  is  used  to  develop  the 
software  code,  which  tool  suite  resides  on  a  desktop 
workstation  in  the  specialist's  office.  The  code  is 
compiled  and  debugged,  copied  to  disk  and  mailed  to  the 
Test  Department.  As  in  the  departments  above,  a  functional 


61 


manager  in  Test  assigns  a  test  specialist  to  execute  the 
software  code  under  a  number  of  various  test  scenarios . 
When  complete,  the  test  results  are  reviewed  by  the 
functional  manager  and  then  sent  along  with  the  software 
code  to  an  independent  verification  and  validation  (IV&V) 
firm,  generally  via  overnight  air  service.  Once  received, 
the  IV&V  representatives  verify  the  results  of  each  step  in 
the  software  development  process  and  validate  the  end 
product  satisfies  the  original  requirements  outlined  by  the 
field  sales  agent.  The  IV&V  results  are  in  turn  forwarded 
to  Field  Sales,  provided  the  software  checks-out  OK. 

It  important  to  note,  at  each  stage  of  the  process, 
some  manner  of  quality  assurance  is  performed,  and  work 
products  (e.g.,  requirements  documents,  software  designs, 
compiled  code)  not  up  to  standards  are  returned  to  the 
originating  department  for  rework.  In  the  case  of  the  IV&V 
step,  work  can  be  returned  back  to  any  of  the  four 
functional  departments  associated  with  the  software 
development.  The  cycle  time  for  this  process  is  generally 
between  one  and  two  months  for  a  relatively  straightforward 
software  implementation. 

B .  PROCESS  MODEL 

The  baseline  software  development  process  can  also  be 
represented  in  terms  of  a  graphical  model  such  as  the  one 
below.  It  includes  the  key  process  activities,  attributes 
and  measurements.  Specifically,  the  six  primary  activities 
from  above  are  included  as  nodes  in  this  graph-based 
representation--!)  Sales  needs  identification,  2) 
requirements  development,  3)  software  design,  4)  coding,  5) 
test,  and  6)  IV&V.  Each  activity  node  is  linked  to  its 
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predecessor  ( s )  and  successor  (s)  through  directed  edges  and 
is  defined  in  terms  of  four  attributes  shown. 


"0"  designates  the  performing  organization  in  the 
process  (e.g..  Sales  Department,  Requirements 
Department ) 

"A"  designates  the  agent  role  in  the  process 
(e.g..  Sales  Agent,  Requirements  Agent) 

"S"  designates  the  information  technology 
employed  for  support  in  the  process  (e.g.,  word 
processor  (WP) ,  computer-aided  software 
engineering  (CASE)  tool) 

"C"  designates  the  media/technology  employed  for 
communication  in  the  process  (e.g.,  phone, 
report ) 


Graph-based  counting  rules  are  used  to  obtain 
measurements  for  the  process.  For  instance,  process  size 
(6)  represents  the  number  of  activity  nodes  in  the  process 
and  process  length  (6)  is  measured  as  the  longest  path 
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through  the  process.  Notice  the  two  feedback  loops  in  the 
diagram  (e.g.,  from  test  back  to  coding  and  from  IV&V  back 
to  design.  They  are  counted  (2)  as  are  the  five  handoffs 
of  work  from  agents  performing  in  different  roles  (e.g., 
from  the  Sales  Agent  to  the  Requirements  Agent)  .  The  WP, 
CASE,  RAD  and  simulation  (sim)  tools  are  counted  in  the  IT- 
support  total  (5)  ,  but  phone-  and  paper-based 
communications  do  not  contribute  toward  the  IT- 
communicat ion  count.  These  measurements  should  suffice  to 
provide  KOPeR  input  for  measurement-driven  inference. 
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APPENDIX  B.  EXPERIMENTAL  CASE  DATA 


A  table  of  explanations  for  assignment  of  quantitative 
assessments  of  the  students'  proposed  redesigns  are 
provided  in  the  following  pages. 

For  each  redesign,  three  passes  are  made  to  evaluate 
the  criteria  laid  out  in  chapter  III  par  A.  The  first 
pass  was  made  by  the  author  and  is  annotated  in  BLACK. 
The  second  pass  was  made  by  Professor  Nissen  and  is 
annotated  in  RED.  The  third  and  final  pass  represents  and 
integration  of  the  two  analysts'  finding  and  is  annotated 
in  BLUE.  The  results  of  this  third  pass  are  what  was  used 
to  populate  the  spreadsheet  contained  in  par  2  below. 

A.  WITHOUT  KOPER-LITE 


Quality 

Subject  # 

Redesig 

n# 

Delinear¬ 

ization 

enablers 

non-value 
added  items 
removed 

jm 

Clarity 

Impact 

Subject  #1 

1 

Y:  Combined 
req  and  design 

0 

0 

0 

-1:With 
creation  of 
Req/design 
team,  one 
handoff  is 
eliminated 

3 

1:  Design/Req 
combo  w/o  IT 
enablers  will 
probably  result  in 
minimal 
improvements 

■ 

N:  stiil 
sequential 

same  PLUS 
OD:  job 
enlargement 

same 

same 

same 

same 

same 

N 

OD:  job 
enhancement 

0 

0 

3 

1 

2 

N 

4:  email, 
workflow  s/w 
(I.e.  Lotus 
Notes),  CASE 
tools, 
computer 
network 

0 

0 

0 

3 

2:  IT  enabled 
comm.  Between 
activities  will 
produce 
noticeable 
Improvements; 
however,  IT  alone 
will  not  result  in 
optimal  results 

same 

same 

same 

same 

same 

same 

same 

N 

4:  email, 
workflow  s/w 
(I.e.  Lotus 
Notes),  CASE 
tools, 
computer 
network 

0 

0 

0 

3 

2 
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4 

0 

0 

•1 

3 

3:  IT  enablers 
combine  with  OD 
changes  and 
reduced  feedback 
loops  will  result  In 
significant 
improvements 

same  PLUS 

OD 

same 

same 

same 

same 

same 

0 

0 

3 

3 

2:  Network, 
email 

0 

0 

0 

2 

1:  Simply 
providing  for 
paperless 
communication  is 
not  enough  to 
realize  significant 
improvements 

Same 

Same 

Same 

Same 

1:  no 
diagram 

same 

2:  Network, 
email 

0 

0 

0 

1 

1 

4:  Email, 
conference 
call,  FTP, 
network 

0 

0 

0 

same 

2 

1:  Additional  IT 
enablers  have 
been  introduced, 
but  there  is  still  no 
mention  of  how  to 
change  work 
processes  to  fully 
realize  the 
benefits  the  IT 
enablers  could 
afford 

Same 

nbox 

Same 

Same 

1:  no 

separation  or 
redesigns 

same 

4:  Email, 
conference 
call,  FTP, 
network 

0 

0 

0 

1 

1 

4:  email,  ftp, 

network, 

internet 

0 

0 

0 

2 

1:  introduction  of 

IT  enablers  is  not 
sufficient  to  bring 
about  significant 
improvement 

Same 

same 

same 

same 

1:  no 
diagram 

same 

4:  email,  ftp, 

network, 

internet 

0 

0 

0 

1 

1 

4:  Conference 
call,  email,  ftp, 
network 

0 

0 

0 

2 

1:  introduction  of 

IT  enablers  and 
automating  "as  is" 
processes  are  not 
sufficient  to  bring 
about  significant 
improvement. 
Processes  should 
be  changed  to 
take  advantage  of 
the  full  potential  of 
IT  enablers 

|1:  no 

separation  of 
[redesigns 


same 


Inbox 


same 


;ame 


same 
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IS 


;ame 


same 


same 


3:IT;  1  non  IT  0 


Subject  #8 


Y:  combine 
Req/Design  and 
Code/Test 

0 

N:  no  mention  of  IT:  email 
delin  IT:  network 

No  statement 
that  trans  or 
cumulative 

N 

2  IT;  0  non-IT 

N 

2 :  email,  FTP 

same 

same 

N 

2  IT;  0  non  IT 

Y:  Req/Design 

3 ;  email. 

activities 

combined 


internet,  FTP 


1 :  addition  of 
customer 
feedback  loop 


same: 
diagram, 
separation, 
but  unclear 


1:  Merging 
activities  with  no 
introduction  of  IT 
or  non-IT 
enablers  will 
produce  little 
more  than  a 
cosmetic  change 


ame 


3:  Integration  of  IT 
and  non-IT 
enablers,  change 
in  processes,  and 
elimination  of 
physical 
separation  of 
activities  together 
promise  to 
increase 
information 
exchange, reduce 
friction,  and 
facilitate  more 
rapid  S/W 
development 
efforts 


ame 


Y:  Req/Design 

activities 

combined 


3  IT; 2  non  IT 


■ ;  email,  0 
internet,  FTP, 
rganizational 
Knowledge- 
Based  system 


9:  This  0:  (same  as 
increase  is  due  above) 
to  the 

incorporation 
of  an 

automated 
knowledge 
base  into 
which  each 
activity  is 
linked 


2:  Though  the  KB 
may  eventually 
prove  as  effective, 
I  believe  there  is  a 
lot  to  be  said  for 
face  to  face 
interaction  in  a 
"creative" 
endeavor  like  S/W 
development 


same: 

diagram, 

separation 
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Subject  #9 


2;  distributed 

database, 

network 

0 

same  PLUS 

IT;  CASE 

same 

2  IT 

0 

OD:  combine  4  same 
depts 


0  IT; 1  non  IT 


1:  email  0 


Same 


1  IT;  0  non  IT 


N;  however,  she  8;  email, 
proposes  using  database, 
a  case  manager  LAN,  workflow 
to  reduce  friction  S/W,  DSS  for  luse  of  Visible 
between  employee 
activities  and  selection, 
maintain  project  internet,  RAD 
status  to  capture  reqs 

awareness  and  generate 
SA/V  prototype, 

Lotus  Notes 


2;  elimination  11 ;  addition  of 
customer 
feedback  loop 


enerate  code 
utomatically. 


-2;  from  5  to  3 
w/  elimination 
of  Code  and 
IV&V  activities 


1;  simply 
automating  a 
single  step 
without  looks  for 
other  ways  to 
benefit  from  IT 
enablers  limits 
impact 


same 


3;  Though  I 
believe  some  of 
her  assumptions 
to  be  flawed  (i.e. 
Coding  can  be 
entirely  through 
automation),  her 
extensive  use  of 
IT  and  non  IT 
enablers,  case 
manager,  and 
process  changes 
to  capitalize  on 
benefits  afforded 
by  IT  enablers 
promise 
significant 
improvement 


ame 


Subject  #1 1 1  Y;  combine  2;  centralized  0 
Code/Test  database, 
activities;  Test  email 
and  IV&V  done 
simultaneously; 
use  of  case  mgr 


2;  from  5  to  7  -  -1 ;  from  5  to  4  2 

feedback  with  integration 

between  all  of  Code/Test 

activities  and 

case  manager 

will  be 

required. 


combining 
Design/Code 
activities  into  an 
integrated  team 
and  bavin 
gTest/IV&V  done 
simultaneously  in 
conjunction  with 
the  use  of  a  case 
manager  coupled 
with  IT  enablers 
such  as  email  and 
shared  databases 
promise 
significant 
improvements 
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same 

Same  PLUS  3: 
??? 

same 

same 

same 

same 

same 

1 

2  IT; 3  non  IT 

0 

2 

•1 

2 

2 

2 

Y:  combine 
sales/reqs, 
Code/Test,  and 
Test  and  IV&V 
done 

simultaneously 

2:  centralized 

database, 

email 

0 

1 ;  from  5  to  6  - 
feedback 
between  all 
activities  and 
case  manager 
will  be 
required. 

■2;  from  5  to  3 
with  integration 
of  Code/Test 
and  Sales/Req 

2 

3;  a  further 
enhancement  of 
his  first  redesign 
which  results  in 
less  friction  and 
additional  job 
enrichment 

same 

Same  PLUS  3: 
??? 

same 

same 

same 

same 

same 

y 

2  IT;  3  non  IT 

0 

1 

•2 

2 

3 

Subject  #12 

1 

N 

3;  LAN, 

database, 

email 

0 

Unable  to 
determine  from 
analysis 

Unable  to 
determine  from 
analysis 

1 

1;  Use  of  IT 
enablers  alone 
will  not  produce 
the  process 
improvements 
sought 

same 

same 

same 

0 

0 

same 

same 

3 

0 

0 

0 

0 

1 

2 

Y:  Combine 
Req/Design 
activities  and 
Code/Test 
activities 

2;  LAN,  VTC 

0 

Unable  to 
determine  from 
analysis 

Unable  to 
determine  from 
analysis 

1 

1;  minimal  use  of 
IT  enablers  and 
lack  of  process 
change  beyond 
just  combining 
activities,  limits 
the  impact  of  this 
redesign 

same 

Same  PLUS 
??? 

same 

■1 

•1 

same 

same 

No 

2  IT; 1  non  IT 

0 

■1 

•1 

1 

1 

Subject  #13 

1 

Y:  states 
"combine 
requirements 
and  design"  and 
then  depicts 
Sales  using  a 
CASE  to 
develop  the 
Reqs,  so  It 
appears  as 
though  he's 
actually 
combined 
Sales/Req/Desi 

gn 

4;  CASE  and 
WP  for  Sales, 
email,  S/Wto 
convert  CASE 
developed  Req 
Doc  into  a 
design  and 
coding  doc 

0 

0;  he  depicts  a 
reduction  from 

2  to  1,  but  he 
eliminates  the 
feedback  loop 
between  IV&V 
and  design 
which  doesn't' 
make  sense  as 
without  this 
feedback  loop, 
the  "final  rpt" 
IV&Vdeveiops 
would  not  be 
returned  to  the 
S/W  dev 
company 

■2;  from  5-3 
with 

combination  of 
Sales/Req/Des 
ign  activities 

2 

2;  Use  of  IT 
enablers  along 
with  work  flow 
redesign  (i.e 
integrating 
Req/Design) 
promises 
moderate 
improvements 

N:  still 
sequential 

same  PLUS 
OD;  combine 
depts 

same 

same 

same 

same; 

diagram,  sep 
of  redeisngs, 
but  unclear 

same 

N 

4  IT; 1  non  IT 

0 

0 

•2 

2 

2 
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73 


75 


Subject  #21 

N 

3:  personal 
computers, 
email,  network 

0 

3:  from  2  to  5 
with  creation  of 
case  mgr  and 
feedback  to 
the  CM  by 
each  activity 
internal  to  the 
S/W 

Development 

division 

0:  handoffs 
•emain  the 

same. 

Though  he 
depicts  an 
additional 
landoff 
between  sales 
and  the  CM  in 
lis  graphic 
■epresentation, 
n  my  textual 
description  of 
lis  redesign, 
ie  states  that 
the  CM  tracks 
and  the 
divisions  hand 
off  to  one 
another 

2 

1:  Moderate  use 
of  IT  enablers  but 
excessive 
reliance  on  case 
worker  increases 
friction  and  1 
believe  may 
actually  result  in 
development 
slowing 

■ 

same  PLUS 
OD: 

empowerment 

0-4  mgrs 

0 

3:  diagram, 
separation 

same 

N 

3  IT;  1  noN  IT 

4 

0 

■3 

2 

1 

2 

Y:  creation  of 
development 
teams 

(Req/Design/Co 

de/Test) 

3:  personal 
computers, 
email,  network 

0 

0:  remains  at  2 

■2:  from  5  to  3 

2 

2:  Moderate  use 
of  IT  enablers  and 
development  of 
Design  Teams 
promises 
increased 
interaction 
between  activities 
thereby  reducing 
friction 

■ 

N:  still 
sequential 

same  PLUS 
OD:  design 
team 

4:  mgrs 

■■ 

3:  diagram, 
separation 

same 

N 

3  IT; 1  non  IT 

4 

■3 

■6 

3 

2 
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B 


WITH  KOPER-LITE 


Subject  # 

Redesign 

# 

Delinearization 

enablers 

change  in  #  of 

feedback  loops 

change  in  #  of 

hand-offs 

Impact 

■ 

N 

4:  DBMS,  email, 
LAN,  WAN 

0 

■1:  elimination  of 

feedback 
between  internal 
Test  and  Code 
activities 

0:  remains 
unchanged  from 
baseline  process 

3 

1:  minimal  use  of 

IT  enablers,  no 
org  change 

same 

same  PLUS 

OD:  1  mgr 

OD: 

empowerment 

manger  review? 

same 

same 

same 

same 

N 

0 

■1 

0 

3 

1 

2 

N 

LAN,  case 
manager 

0 

0:  unchanged 
(not  addressed  in 
redesign) 

0:  unchanged 
(not  addressed  in 
redesign) 

1 :  diagram  does 

not  depict  case 
manager 
involvement  or 
feedback  loops. 
Metrics  are  not 
orovided  for  the 
second  redesign 

1:  minimal  use  of 
IT  enablers;  case 
manager 
inserted,  but  roll 
not  described; 
process  changes 
not  discussed 

same 

Same 

1 

same 

same 

same 

same 

n 

1 

1 

0 

0 

0 

1 

Subject 

m 

1 

Y:  use  of 
Design/Code/T 
est  teams,  use 
of  Case 
Manager 

8:  email,  EDI  via 
online  customer 
request  form, 
shared  database, 
experty  system 
for  requirements 
integration, 
network,  LAN, 
VPN,  use  of 
internet 

0 

■1:  from  2  to  1 
with  the 
elimination  of 
feedback 
between  Code 
and  Test 
activities  in  light 
of  the  new 
"team"  concept 

■2:  from  5  to  3 

2 

3;  extensive  use 
of  IT  enabler, 
organizational 
design  altered 
and  discussion  of 
work  process 
changes 
highlighted, 
inclusion  of  case 
manager  and 
development 
team  concept 

same 

manger  review? 

same 

same 

2:  diagram, 
unclear 

same 

N 

8  IT:  0  non  -IT 

0 

■1 

■2 

2 

3 

1 

Y:  integrated 
req/design/cod 
e/test  team 

4 :  LAN,  shared 
files,  email, 
automated 
requirements 
generation  tool 

0 

■4:  from  5  to  1 
with  creation  of 
integrated 
development 
team 

■3:  from  5  to  2 
with  creation  of 
integrated 
development 
team 

2 

3;  significant  use 
of  IT  and  non-IT 
enablers,  ease 
mgr,  devel  team, 
steps  to  reduce 
friction,  facilitate 
comms 

Same 

same 

same 

same 

1 :  hard  to  follow 

same 

N 

0 

■4 

■3 

2 

3 
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: case  0 
manager  for  all 
but  IV&V 
activities 


Y:  case  4:  internet, 

manager  for  all  intranet,  shared 
but  IV&V  database,  LAN 

activities  plus 
creation  of 
Req/Design/Co 
de  team 


4:  from  5  to  1 
with 

incorporation  of 
case  manager 


1:  use  of  case 
manager  will 
decrease  friction 
but  will  not 
facilitate  speed 
of 

communications 
in  light  of  no  IT 
enablers  for 


4:  from  5  to  1 
with 

incorporation  of 
case  manager 


2:  use  of  IT 
enablers  in 
conjunction  with 
case  manager 
concept, 
however,  this 
redesign  seems 
to  imply  business 
is  done  the  same 
basic  way  even 
though  some 
steps  are  now 
digitized. 


4:  from  5  to  1 
with 

incorporation  of 
case  manager 


3:  extensive  use 
of  IT  and  non-IT 
enablers,  case 
manager, 
development 
teams,  work  flow 
redesign 
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6:  server-based  -7:  elimination  of  0:  remain  same 
network,  FTP,  "mail"  process  as  baseline 

internet,  accounts  for  5  of 

webpage,  email,  these  eliminated 
expert  system  processes 


6:  server-based 
network,  FTP, 
internet,  emaii, 
expert  system, 
code  generator 


7  IT: 0  non  IT 


:  combined  5:  Group  ware, 
Sales/Require  workflow  system, 
ments  expert  system, 

consolidated  all  and  implied  are 
the  various  internet/intranet 

processes 
performed  by 
Individual 
"organizations” 
into  single 
activities. 


6  IT: 0  non  IT 


6:  server-based  -10:  elimination 
network,  FTP,  of  mail 
internet,  processes  plus 

webpage,  email,  automation  of 
expert  system  code  generation 
account  for  these 


-12:  elimination 
of  13  processes 
and  the  addition 
of  one  new  one., 
the  "customer 
advocate." 
Requirements 
process  is 
greatly 

streamlined  and 
snail  mailing  of 
outputs  to  follow- 
on  activities 
eliminated  with 
incorporation  of 
additional  IT- 
automation 


-4:  from  7  to  3; 
some  feedback 
loops  resulted 
from  his  analysis 
and  breaking 
down  activities 
into  their 
component 
processes. 


-12:  from  17  to  5; 
this  results  I 
large  part  do  to 
his  consolidation 
of  all  the  various 
processes 
performed  by 
individual 
"organizations" 
into  single 
activities. 


2:  moderate  use 
of  IT  enablers  to 
decrease  comm. 
Delays,  no  work 
flow  or  process 
changes  to 
compliment  IT 
enablers. 


3: :  change  in 
work  processes, 
activity 

automation  (i.e. 
code 

generation), 
further  reduction 
in  handoffs 


2:  moderate  use 
of  It  and  non  IT 
enablers  (case 
manager) 


80 


same 


Y:  5:  Group  ware,  -13:  elimination 

Development  workflow  system,  of  1 5  processes 
of  expert  system,  and  the  addition 

Design/Code/T  and  impiied  are  of  two  new 
est  teams  internet/intranet  ones.,  the 

)  "customer 

advocate"  and 
"form  new 
product  team." 
Requirements 
process  is 
greatiy 

streamlined  and 
snail  mailing  of 
outputs  to  follow- 
on  activities 
eliminated  with 
incorporation  of 
additional  IT- 
automation 


, :  Group  ware, 
expert  system, 
and  implied  are 
internet/intranet 
OD:  customer 
advocate 
OD:  eliminate 
depts.  (case 


-6:  from  7  to  1;  -13:  from  17  to  4; 

however  he  again  this  results 

doesn't  consider  I  large  part  do  to 
the  feedback  that  his  consolidation 
must  happen  of  all  the  various 

with  the  inclusion  processes 
of  a  "customer  performed  by 
advocate"  (aka  individual 
case  manager),  "organizations" 


3:  moderate  use 
of  IT  enablers 
coupled  with 
non-it  enablers 
like  customer 
advocates  and 
development 
teams  expected 
to  yield 
significant 
improvements 


2:  minimal  use  of 
IT  enablers, 
good  use  of  non- 
IT  enablers  such 
as  case  mgr  and 
development 
teams 
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3:  online  form,  0 
internet,  intranet 


-1:2to1  w/ 
creation  of 
Development 
Team 


■2:  from  5  to  3  w/ 
creation  of 
fevelopment 
earn 


Same  PLUS 

same 

same 

s 

ame 

al 

OD:  combine 
des/code/test 

3  IT: 1  non  IT 


Design/Code  form,  internet, 
combined  as  a  intranet,  email 
single  activity 


5:  website,  online  -1 :  elimination  of  -1 :  from  2  to  1  w/  -2:  from  5  to  3 
sales;  customer  loop  going  from  with  elimination 
submits  IV&V  to  Design  of  Sales  and 

requirements  via  combination  of 

the  web  Design/Code 

activities 


same 


5  IT: 0  non  IT 


Internet/intranet, 
electronic  form, 
email,  automated 
requirements 
document 
development  tool 


same 


5  IT: 0  non  IT 


Internet/intranet, 
electronic  form, 
email,  automated 
requirements 
document 
development  tool 


Same  PLUS 
OD:  combine 
des/code/test 
OD:  single  mgr 


5  IT: 2  non  IT 


2:  good  use  of  IT 
comm.  And  IT 
support  in  Code 
activity. 
Elimination  of 
Sales  is  not  seen 
as  an 

enhancement  as 
many  customers 
benefit  from  the 
give  and  take  w/ 
a  person  when 
rying  to  clearly 
articulate  their 
needs/reqs 


same 


2:  moderate  use 
of  IT  enablers 
but  little  change 
to  underlying 
processes 


-1 :  from  2  to  1  w/  -2:  from  5  to  3 
creation  of  with  creation  of 
integrated  integrated 

Design/Code/Tes  Design/Code/Tes 
t  team  t  team 


83 


84 


-2:  from  5  to  3 

1:  unclear  which 

with  creation  of 

activities  are 

single 

combined  either 

Design/Code/Tes  by  reading  or 

t  activity 

referring  to 

same 

redesign  digraph 

N  p  IT:  1  non  IT  0 


:  Combine  7:  LAN/WAN, 
Design/Code/T  email,  shared 
est  activities  databases, 

electronic  forms, 
electronic 
graphical 
representation, 
VTC,  CAD 


7  IT:  1  non  IT  0 


same  PLUS 
automatic  queue 
system _ 


6  IT:  0  non  IT  0 


.  :  Computer 
network 

(implied),  email, 
partial  auto  form 
population,  auto 
form  verification 


-1:  sales 
eliminated 


same  PLUS 
OD  Remove 
Sales 


0:  unchanged  -2:  from  5  to  3  1:  unclear  which 

from  baseline  with  creation  of  activities  are 

single  combined  either 

Design/Code/Tes  by  reading  or 
t  activity  referring  to 

redesign  digraph 


0:  unable  to 
determine 


0:  unable  to 
determine 


1 :  good  use  of  IT 
enablers,  no 
non-IT  enablers 
(case  mgr,  team 
concept,  etc)  and 
little  discussion 
on  changing 
underlying  work 
processes.  No 
delin 


1 :  good  use  of  IT 
enablers,  no 
non-IT  enablers, 
elim  of  sales  may 
limit  ability  to 
capture  customer 
needs  as  a  sales 
person  can 
probably  help 
capture  customer 
needs  more 
completely 


same 
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2:  email,  network  0 
esign/code/te  (implied) 
tteam 


1:  minimal  use  of 
IT  enablers,  use 
fo  devel  team 
conoept,  but  no 
disoussion  on 
changing 
underlying 
processes  or 
delinearizing 
activities 


req/design/cod  (implied) 
e/test  team 


same  PLUS 
OD:  case  team 


2  IT:  1  non  IT  0 


2;  email,  network  0:  though  unclear  Not  addressed 


if  req  is  merely 
combine  w/  the 
case  team  or 
eliminated 


Not  addressed  -3:  from  5  to  2  1 :  failure  to 

by  redesign;  with  address 

feedback  fraction  incorporation  of  feedback  loops 

of  0.167  is  req/design/code/t  makes  it 


yielded  by 
KOPeR  output, 
but  unable  to 
determine  how 
this  number 
could  be  reached 
based  on  what's 
depicted  in  his 
digraph 


same  PLUS 
OD:  case  team 


2  IT: 1  non  IT 


2:  email,  network  -1 :  elimination  of  -1 :  from  2  to  1 
IV&V  with  elimination 

of  IV&V  and  its  IV&V 
resultant 
feedback  loop 


mpossible  to 
analyze  this 
element  of  his 
'edesign;  also, 
unclear  whether 
'eq  is  added  to 
the  Case  Team 
or  if  this  activity 
s  simply 
eliminated 


1:  minimal  use  of 
IT  enablers,  use 
fo  devel  team 
concept,  but  no 
discussion  on 
changing 
underlying 
processes  or 
delinearizing 
activities 


-1 :  from  5  to  4  w/ 
elimination  of 


3:  IT  and  non-IT 
enablers,  case 
team,  case 
manager  concept 
all  integrated 
with  discussion 
on  changing 
underlying 
processes  (i.e 
requirements 
development 
process) 


same  PLUS 
WF:  eliminate 
IV&V 

OD:  combine 
Sales/Req 
IT:  Req  DSS 
OD:  PM 


3  IT: 2  non  IT 


2:  email,  network  -1 :  elimination  of  L2:  from  2  to  0 
IV&V 


'  -2:  from  2  to  0  -3:  from  5  to  2 

with  elimination  with  elimination 

of  IV&V  and  of  IV&V  and 

creation  of  creation  of 

Design/Code/Tes  Design/Code/Tes 
t  team  where  1  team 

feedback  would 
occur 

consequent  to 
the  iterative 
nature  of  the  new 


imanager 


3:  good  use  of  IT 
and  non  IT 
enablers,  case 
team,  case 
manager, 
iterative 

development  and 

incremental 

testing 
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APPENDIX  C.  KOPER  PATHOLOGY  DIAGNOSIS  AND  REDESIGN 
ADVICE;  PCS  ORDERS  PROCESS  FOR  USMC  OFFICERS 


A.  BASELINE  PROCESS 

1 .  Diagnosis 

Measurements  (e.g.,  size  of  5)  suggest  the  small  PCS 
orders  Process  for  USMC  Officers  process  suffers  from  the 
following  pathologies: 

•  Parallelism  (1.0)  -  sequential  process. 

•  Handoffs  fraction  (0.8)  -  process  friction. 

•  Feedback  fraction  (0.6)  -  checking  &  complexity. 

•  IT  support  fraction  (2.2)  -  IT  support  looks  OK. 

•  IT  communication  fraction  (0.6)  -  IT 

communication  looks  OK. 

•  IT  automation  fraction  (0.0)  -  inadequate  IT 

automation . 

2 .  Recommendations 

For  redesign,  we  recommend  you  consider  the  following: 

•  Delinearize  process  activities  to  increase 

parallelism;  such  activities  must  be 

sequent ially-independent  (e.g.,  have  mutually- 

exclusive  inputs  and  outputs)  . 

•  Try  a  case  manager  or  case  team  to  decrease 

friction;  be  sure  to  include  a  source  of 
expertise . 

•  Try  empowerment  to  reduce  the  amount  of  checking 
in  the  process;  be  sure  to  address  training  and 
incentives . 

•  Look  to  information  technology  to  automate 

process  activities;  automated  transaction 
processing  and  expert  systems  generally  have  good 
payoffs  and  intelligent  agents  can  enable  many 
electronic  commerce  opportunities. 

•  Try  either  asynchronous  or  contemporaneous 

reviews  to  conduct  quality/f eedback  loops 
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concurrently  or  jointly;  scheduling  becomes  a 
concern  with  this  redesign. 

In  addition  to  delinearization  and  the  use  of  a 
case  manager,  workflow  systems  offer  good 
potential  for  process  improvement;  try  to  avoid 
paving  the  cowpaths  by  ignoring  other  process 
pathologies,  however. 


B.  REDESIGN  ALTERNATIVE  #1 

1 .  Diagnosis 

Measurements  (e.g.,  size  of  5)  suggest  the  small  PCS  Orders 
Process  for  USMC  Officers  suffers  from  the  following 
pathologies : 

•  Parallelism  (1.0)  -  sequential  process. 

•  Handoffs  fraction  (0.8)  -  process  friction. 

•  Feedback  fraction  (0.2)  -  feedback  looks  OK. 

•  IT  support  fraction  (2.2)  -  IT  support  looks  OK. 

•  IT  communication  fraction  (0.6)  -  IT 

communication  looks  OK. 

•  IT  automation  fraction  (0.2)  -  inadequate  IT 

automation . 

2 .  Recoimnendations 

For  redesign,  we  recommend  you  consider  the  following: 

•  Delinearize  process  activities  to  increase 

parallelism;  such  activities  must  be  sequentially 
independent  (e.g.,  have  mutually-exclusive  inputs 
and  outputs)  . 

•  Try  a  case  manager  or  case  team  to  decrease 

friction;  be  sure  to  include  a  source  of 
expertise . 

•  Look  to  information  technology  to  automate 

process  activities;  automated  transaction 
processing  and  expert  systems  generally  have  good 
payoffs  and  intelligent  agents  can  enable  many 

electronic  commerce  opportunities. 

•  In  addition  to  delinearization  and  the  use  of  a 

case  manager,  workflow  systems  offer  good 
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potential  for  process  improvement;  try  to  avoid 
paving  the  cowpaths  by  ignoring  other  process 
pathologies,  however. 


C.  REDESIGN  ALTERNATIVE  #2 

1 .  Diagnosis 

•  Measurements  (e.g.,  size  of  4)  suggest  the  small 
PCS  Orders  Process  for  USMC  Officers  process 
suffers  from  the  following  pathologies: 

•  Parallelism  (1.0)  -  sequential  process. 

•  Handoffs  fraction  (0.75)  -  process  friction. 

•  Feedback  fraction  (0.25)  -  feedback  looks  OK. 

•  IT  support  fraction  (1.75)  -  IT  support  looks  OK. 

•  IT  communication  fraction  (0.75)  -  IT 

communication  looks  OK. 

•  IT  automation  fraction  (0.75)  -  IT  automation 

looks  OK. 

2 .  Recommendations 

For  redesign,  we  recommend  you  consider  the  following: 

•  Delinearize  process  activities  to  increase 

parallelism;  such  activities  must  be  sequentially 
independent  (e.g.,  have  mutually-exclusive  inputs 
and  outputs) . 

•  Try  a  case  manager  or  case  team  to  decrease 

friction;  be  sure  to  include  a  source  of 
expertise . 

•  In  addition  to  delinearization  and  the  use  of  a 

case  manager,  workflow  systems  offer  good 
potential  for  process  improvement;  try  to  avoid 
paving  the  cowpaths  by  ignoring  other  process 

pathologies,  however. 
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APPENDIX  D.  EXPLANATIONS  OF  KOPER  REDESIGN 

RECOMMENDATIONS 


A.  DE-LINEARIZE 

De-linearization  involves  rearranging  a  sequence  of 
process  activities  to  be  performed  in  a  more  parallel  or 
concurrent  manner.  Process  parallelism  or  concurrency  has 
positive  performance  effects  in  terms  of  cycle  time  (and 
often  cost) ,  as  activities  are  performed  in  parallel  as 
opposed  to  sequentially.  This  redesign  transformation 
affects  the  sequence  and  flow  of  process  activities,  but 
not  how  or  by  whom  they  are  performed. 

B .  CASE  MANAGER 

The  case  manager  transformation  involves  replacing 
specialized  employees  in  a  process  (often  from  different 
functional  departments)  with  a  generalist  case  manager  who 
performs  all  process  activities  from  start  to  finish.  A 
case  manager  can  have  positive  performance  effects  in  terms 
of  cycle  time  (and  often  cost)  ,  as  a  single  case  manager 
obviates  the  need  for  handoffs  and  inter-departmental 
coordination.  A  case  team  involves  the  same  concept 
extended  to  a  dedicated  team  of  people.  In  the  DoD,  these 
are  referred  to  as  'integrated  product  teams'  (IPTs) . 

C .  EMPOWERMENT 

Empowerment  involves  delegating  responsibility  to 
front-line  employees  and  authorizing  the  people  doing 
process  work  to  ensure  the  quality  of  their  work. 
Empowerment  can  have  positive  performance  effects  in  terms 
of  cost  and  cycle  time,  as  quality  'checking'  steps  can  be 
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avoided  and  empowered  employees  often  produce  superior  work 
products  at  lower  cost.  Empowerment  entails  some  job 
enlargement . 

D .  IT  SUPPORT 

IT-Support  involves  the  application  of  information 
technology  (IT)  to  support  process  activities.  This 
powerful  redesign  transformation  can  have  positive 
performance  effects  in  terms  of  cost  and  cycle  time,  as 
computer-based  tools  can  augment  human  performance  in  terms 
of  memory,  speed,  thoroughness  and  other  attributes.  As  a 
'support'  enabler,  IT  in  this  class  is  used  in  conjunction 
with  human  labor  (i.e.,  in  contrast  to  IT-Automat ion)  . 


E .  IT  COMMUNICATION 


IT-Communicat ion  involves  the 
information  technology  (IT)  to 
communications.  This  powerful  redesign 
have  positive  performance  effects  in 
cycle  time,  as  computer-based  tools  can 
based  communications. 


application  of 
support  process 
transformation  can 
terms  of  cost  and 
replace  slow  paper- 


F .  IT  AUTOMATION 

IT-Automat ion  involves  the  application  of  information 
technology  (IT)  to  automate  process  activities.  This 
powerful  redesign  transformation  can  have  positive 
performance  effects  in  terms  of  cost  and  cycle  time,  as 
computer-based  tools  can  replace  and  improve  human 
performance.  As  a  'automation'  enabler,  IT  in  this  class  is 
used  to  obviate  human  labor  (i.e.,  in  contrast  to  IT- 
support) . 
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G .  JOINT  REVIEWS 

The  joint  reviews  transformation  serves  to  eliminate 
the  pathologies  associated  with  a  sequence  of 
quality/f eedback  loops  in  a  process.  This  can  have  positive 
performance  effects  in  terms  of  cycle  time,  as  reviews  are 
handled  once  by  all  interested  parties.  However,  this 
approach  can  actually  increase  cost  if  reviews  are  not 
managed  effectively.  Scheduling  also  becomes  a  concern. 

H .  SEQUENTIAL  INDEPENDENCE 

Delinearization  can  significantly  reduce  process  cycle 
time,  particularly  when  high-level  process  activities  are 
delinearized.  But  if  two  process  activities  are 
sequentially  dependent,  they  cannot  be  performed 
concurrently;  rather,  they  must  continue  to  be  performed  in 
series . 

One  test  for  sequential-independence  is  to  analyze  the 
inputs  to,  and  outputs  from,  each  process  activity.  Where 
the  inputs  to  an  activity  (call  it  Step-2)  are  not  produced 
by  the  preceding  activity  (call  it  Step-1),  the  two 
activities  offer  good  opportunity  to  be  performed  in 
parallel . 


I .  EXPERTISE 

When  a  case  manager  or  case  team  is  instituted,  the 
personnel  performing  in  such  process  roles  are  usually 
generalists--broadly  skilled  in  at  number  of  different 
jobs--who  are  seldom  endowed  with  expertise  across  all 
required  tasks  and  activities. 
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The  generalist  worker  (s)  can  be  expected  to  perform 
well,  so  long  as  the  process  activities  are  not  unusual, 
complex  or  novel.  Performance  of  work  that  is  not 
customary,  simple  and  familiar  often  requires  deeper 
expertise  than  is  possessed  by  a  generalist  case  manager. 
Thus,  expertise  is  required  to  support  the  generalist  in 
these  situations. 

Expertise  is  most  commonly  provided  through  retention 
of  some  expert  personnel,  who  can  serve  as  advisors  or 
internal  consultants  when  problems  arise.  With  the  advance 
of  knowledge  systems  technology,  however,  much  of  this 
expertise  can  be  captured  and  formalized  through 
intelligent  systems.  Expert  systems  for  problem  diagnosis, 
neural  networks  for  pattern  recognition,  case-based 
reasoning  systems  for  help  desks,  intelligent  agents  for 
information  filtering,  and  other  intelligent  applications 
represent  potential,  alternative  sources  of  expertise. 

J.  TRAINING  AND  INCENTIVES 

Empowerment  can  create  a  number  of  process 
improvements  by  authorizing  decisions  to  be  made  personnel 
who  are  directly  responsible  for  performing  process  work. 
This  can  eliminate  lengthy  decision-making  and  feedback 
loops,  and  can  augment  process  quality. 

However,  employees  who  are  unaccustomed  to  making 
decisions  are  likely  to  require  training,  in  addition  to 
having  the  requisite  decision-making  information  provided. 
This  represents  a  critical  factor  to  the  success  of 
empowerment . 
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Personnel  who  are  newly  empowered  are  also  likely  to 
perceive  a  (real)  increase  in  their  level  of 
responsibility.  This  represents  a  key  motivating  factor 
behind  the  increased  process  quality  noted  above,  but  the 
personnel  must  also  be  incentivized  to  take-on  this 
additional  (perceived)  responsibility.  Monetary 
compensation  is  not  necessarily  required,  as  employer- 
sponsored  training,  expanded  job  title,  business  cards, 
improved  office  surroundings  and  other  factors  can  also 
incentivize  many  people. 

K.  IT  TRAINING  AND  MAINTENANCE 

Information  technology  represents  a  very  powerful 
enabler  of  process  innovation.  IT  to  support  process 
activities  and  communications  requires  personnel  training 
in  many  organizations,  however.  Indeed,  many  techno-phobic 
employees  will  find  new  IT  threatening,  and  are  likely  to 
resist  change.  Training  represents  one  approach  to 
addressing  such  employees. 

Techno-phobic  or  not,  simply  inserting  new  IT  into  a 
(human)  process  cannot  be  expected  to  produce  dramatic 
process  improvements  unless  the  personnel  are  adequately 
trained  to  use  the  IT.  Although  this  appears  evident,  many 
good  redesigns  have  failed  for  lack  of  training. 

Additionally,  IT  needs  to  be  maintained.  Computer 
hardware  requires  repair  and  upgrading.  New  releases  of 
software  require  installation.  Databases  and  networks 
require  administration.  Indeed,  software  maintenance,  for 
example,  is  known  to  consume  roughly  two-thirds  of  the 
total  life  cycle  cost  for  software. 
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L.  AUTOMATION  AND  ELECTRONIC  COMMERCE 

Automation  implies  that  IT  is  being  employed  to 
perform  process  activities  instead  of  people,  and 
represents  a  different  class  of  redesign  transformation 
than  either  IT  support  or  communication.  Yet  an 
infrastructure  of  IT  for  support  and  communication  is 
generally  necessary  for  effective  automation. 

Automated  transaction  process  systems  are  well  known 
for  this  effect  and  expert  systems  are  increasingly  being 
used  to  automate  some  aspects  of  knowledge  work.  With  the 
advent  of  intelligent-agent  technology,  automation  is 
reaching  beyond  routine  transactions  and  self-contained 
expertise,  and  extending  across  network  linkages  to 
automate  coordination  and  collaboration  work  as  well. 

Much  coordination  and  collaboration  work  is  now 
accomplished  between  organizations  and  intelligent  agents 
are  playing  an  increasingly  important  role  in  this  area. 
For  example,  using  former  EDI  connectivity  links, 
customers,  channels  and  suppliers  are  finding  an  enhanced 
ability  to  locate,  interact  and  conduct  business  with  one 
another,  without  human  intervention. 

M.  IT  INFRASTRUCTURE 

An  IT  infrastructure  is  particularly  important  to 
support  the  automation  of  knowledge  and  information  work, 
and  is  generally  considered  to  represent  a  necessary 
precondition  for  success.  IT  to  support  process  activities 
(e.g.,  computers,  software,  decision  support  systems, 
databases,  word  processors,  etc.)  and  communications  (esp. 
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e-mail.  Intranets,  workflow  systems)  represent  key 
infrastructural  elements. 

A  workflow  system  is  often  required  to  support  many 
approaches  to  knowledge-work  automation,  particularly  where 
work  crosses  agent  roles  and  organizational  boundaries. 
Intelligent  agents  require  knowledge  and  information  in 
digital  form,  so  these,  basic  IT  infrastructural  elements 
are  required  even  to  begin  such  automation  work. 


N .  SCHEDULING 

Asynchronous  reviews  are  less  prone  to  scheduling 
concerns  than  their  contemporaneous  (i.e.,  joint) 
counterparts.  When  busy  people  must  interact  jointly, 
finding  mutually-acceptable  slack  times  in  their  schedules 
becomes  exponentially  more  difficult  as  the  number  of 
required  participants  increases. 

Setting  aside  fixed  times  during  the  day,  week,  or 
month  to  address  such  reviews  represents  one  approach  to 
addressing  scheduling  concerns,  and  minimizing  the  number 
of  required  attendees  is  another  proven  heuristic.  Also 
ensuring  that  all  issues  that  can  be  resolved  before  such 
meetings  can  be  crucial. 

O .  WORKFLOW 

Workflow  systems  can  support  process  activities 
through  shared  databases  and  networked  communications,  in 
addition  to  automatically  routing  work  to  the  right 
agent (s)  at  the  right  time.  This  can  save  both  process  time 
and  money.  However,  see  the  caution  above  regarding  IT 
training  and  maintenance. 
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Most  extant  workflow  applications  are  relatively 
rigid,  in  that  once  a  process  is  defined,  it  cannot  be 
changed  dynamically  (e.g.,  in  response  to  in-process 
circumstances)  .  Also,  unless  the  underlying  process  work 
itself  is  changed,  a  workflow  system  can  simply  "pave  the 
cowpaths"  and  speed-up  the  current  "broken"  process. 
Indeed,  with  new  interfaces  and  without  personnel  training, 
workflow  systems  can  even  increase  process  cycle  time, 
despite  electronic  communications  that  occur  at  speeds  near 
that  of  light. 

The  key  is  to  redesign  the  underlying  process  work 
first,  then  ensure  an  adequate  IT  infrastructure,  then  look 
into  workflow  automation.  As  a  note,  workflow  systems 
provide  a  wonderful  infrastructural  foundation  for 
intelligent-agent  applications. 
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